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^4. Jan. 2007 

Llirtroduction ^^^^ 

WAin Siemois Surpass product femjly, liie vahie-added IP services become more and more important and sho^ 
new needs in terms of psiEbnnance and reliability. This is flie reason the running environment of fliese services 
has to be realized fir cairisr-grade scaling and avaflability. like in fbs BWSD, solid overload detection and 
handling medbanisms are the preoondMon for an optimized use of the resources and a hi^er robustnera of tide 



It has been diosen to develop and implement these sa^c^ on fee so-called Commercial Platform (OOPL) wbidi 
relies on a SUNhn madiine running Sun's Solaris tm v2.6 (in fiiture v8) opoBting systrai. 

The described in ibis document tsikes into account Ihe ftct fliat the COPL deals with other kinds of 

q)plications than the EWSD does, Ihese applic^ons are from two groups: a first groiq> fliat defizies the Open 
S^Adce Platform (OSP) and a second groiq> flaat defines ihe Padket Control Unit (PCU). All these plications deal 
vnSi IP-networks and IP-services. They need other measurements andhandling medianisms tihan the one used in the 
EWSD processes. 

A typical Internet Services Serv^ does not provide any support to limit flie rate of connections per second and/or flie 
rate of reqpiests pa* second to dynamicalfy ad^ to server load and/or satisfy a policy constraint on savitte 
guarantees. As a result* it is likety for an Intemet Services Server to become saturated (overloaded) \vhm servicing 
content to clients. In m overloaded condition, a typical server sofEers severe performance degradation, with the 
overall throu^put felling significantly and client connectivity and perceived performance (sudi as the delay in 
ccmpledng ttie request) becoming unpredictable. 

Jn addition to suscqplibility to overload, curr«t servers lade ftxe ability to monitor flie mcoming load and 
difGarmtiate betweai different types of services, especialfy in scenarios sudi as virtual hosting in wMdi multiple 
services (e.g,, different Ihteanet sendee applications) may be co-located on the same servo- platform. Without 
overload protection and service dtfifearentiation, a typical server vronid onty be able to provide 'T)est effort" service to 
its customers. 

2. How has this problem been solved up to now? 

2.1 Usually a predefined llireahold (determined during load test in a test-lab) is defined per application (number of 
paralld sessirai maximal number of waiting events in fee queue or more generic resources like CPU or memory 
use) and tide given s^lication rejects all new incoming load if fiiis tiire^old is readied. 

2.2 Another mefhod is to add a Load Balancer before the considered madune in order to tail the incoming load 
between a given set of sunilar machines. In fiiis mefliod, the threshold used in 2.1 is used in this ojctta-madune. 
IxmdBalandng is more used in order to avoid rejecting new incoming load. It does not solve overload fiir a smgle 
madune. 



3 . In what manner does your uivention solve the technical problem indicated (show advantages)? 

The invention relies cai a fiexible and adq^ytable overload detection and overload hapdlnyg mechanism. 

This medianism is based on the use of a fuzzy logic expert system (developed by the author). This fiizzy logic 
expert system computes in a first step (NOM, Normal C^e^on Mode) an overload level (load monitoring and 
overload detection) fijr the system according to die monitored resources (Iflce CPU, memoiy, los, queues. . . ) and to a 
predefined fuzzy logic rul^-based scenario. If a defined overload level is readied, ften fiie FLEXSYS (Fuzzy Logic 
Expert SYStem) compute in a second step (OOM, Ovwload Operation Mode) vihidi overload handlmg actions 
(ovCTload handling) have to be taken (accordmg to a second FLEXSYS scenario). 
The complete load control system can be seen in fiie following sdiematic: 




Figure 1: Fuzzy Logic Based Load Control System 
for MuUimedia/T sleoommuniGation Platforms 
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1 Realization 

The invention rdies on a flexible and ad^table overload detection and ov^load handling medianism. This 
mechanism is based on tiiense of a fiizzy logic &qpext system (devdoped by tiie auttxor). This fiizzy lo^c expert 
s>^em computes in a first stqp CNOM, Nonnal C^eration Mode) an overload level (overload detection) for fee 
system according to monitored resources (like CPU, memory, los, queues...) and to a predefined fiizzy logic rule- 
based scenario. If a defined overload level is readied, then flie FLEXSYS (Fuz^ Logic EXpert SYStem) computes 
in a second step (OOM, Overload Opoation Mode) which overload handling measures (overload handlbg) have to 
be taken (according to a second FLEXSYS scenario). 
The complete load control ^stem can be seen in file following sdiemstic: 




FigufB 2: Fuzzy Logic Based Load Control System 
for Multimedia/T alecommunioation Platforms 



1.1 Overioad Detection 

Overload detection enoompasses a set of stages like local and remote resources load monitoring, 
calculation df an overall overload level, system status switching and start of the overioad treatment. 



1.1.1 Local COPlr Overload Detection 

Like in CP load control, the COPL overioad levels rank from 1 to 6. 

However, in contrast to the concept of CP overioad control there are no explidt load states defined for the 
COPL, i.e. the COPL is considered not to be under overioad if the "over-" load level is set to 0. 
(Nevertheless the transition t>etween the level 0 and level 1 is treated differently than the transition 
between on to the other levels (1...6)0 




1-1, LI Load Momtoring Process 

The CoPVs operating ^stem (UNIX, SUN Solaris) consists of applications and processes ftat are called 
by the kernel (endless loop) depending on their priority, in this environment, the LMP (Ijoad Monitoring 
Process) should run as a ^ngle process. It should be quick and flme .intenrupt driven. It should get a 
higher priority but not use more than a predefined amount of memory and CPU time pro run (budget 
defined in Eri). 

The LMP has to monitor different Wnds of resources: 

> CPU usage 

> Memory usage 

> I/O usage 

> Overall System Overioad 

> Applications specific resources 

The LMP must have two running modes: .... 

> a basic one In non-overioaded operation in order to detect .an overioad situation by cheddng a 
restricted amount of main resources like cpu, m^ory and los, 

> an overioad mode running under overioad situation, ^AA1ich makes a more detailed analysis of the 
overioad situation and that runs with a higher frequency and checks an higher amount of r^urces 
(not only cpu, m^ory and kss, tnit also application q3edfic ones). 

Under normal situation, the LMP only checks the operating status of the whole system and. In case of 
detection of a possible overioad situation, switches to its overtoaded mode. 

In overioaded mode, tiie LMP checks the same way as the basic mode but with a higher frequency, a 
second time-loop checks extra resources in order to possibly detect the overioad responsible application. 



Normal Operation Mode 



Overload Operation Mode 
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Figure 3: Operatton modes of the LMP (NOM/OOM) 




The left part of the Overload OperaHon Mode (OOM) is very similar to the Normal Operation Mode 
(NOM); the main difference is the control loop frequency. If the chosen programming technique allow It, 
the two processes could be merged Into one (with two threads). 

The NOM must be a light process, checldng a restricted fix amount of main resources. It is not correlated 
to the running applications on the COPL It says if the COPL (globally) should enter the OOM. This part of 
the LPM is the ^me for all versions of the COPL, \\ke for example the PCU or the OSP. It can rely on an 
optimized Fuzzy Logic Kernel running in C or Assembler (for higher speed), a prototype is available from 
the SRIT. its configuration can be adapted tiirough its FL-Modei configuration file (like a script or 
dat^ase). An other aspect Is that the NOM conserves some values between its runs and uses them to 
eliminate some kinds of problems like short-time overloads that do not require an overlc^d treatment 
Typically tiie NOM calculates the "climbing factor^ or increase/decrease coefficient (df/dt). 

The OOM is should stay a light process (not more than 50% more resource consumption than the NOM), 
checking a higher amount of resources (tifie same as NOM and additional application speciflc resources). 
It relies on a Fuzzy Logic driven expert system that can compute which measures have to be taken In 
order to drive tiie COPL back to the NOM. Its configuration can be adapted through its FL-Model 
configuration file (fike a script or database). A kind of overtoad responsibility check is perfomned by tiie 
OOM. According to the faults, some signals are sent and actions are taken to the diverse components of 
the COPL. It deddes how the Overioad Treatment has to work. The OOM FL-Model depends on ttie 
applications running on the COPL. 



1 .1. 1 .2 Monitored resources 
1.1.1 CPU (NOM/OOM) 

The global CPU load (in opposition to the process cpu load) <^n be chebked using standard OS functions 
or UMLA API. The returned value Is a percentage of the v\^ole cpu capacity (in a further step, it could be 
a per-cpu measurement in case of multiple cpu or ...). Before using this raw measurement, it can be 
useful to go through an intermediate state, making the cpu raw measurement correspond to a cpu 
overload level (OVLjCPU). This Intermediate steitement is mostiy useful If tiie NOM does not rely on 
Fuzzy Logic, indeed the FL performs automaticalty such conversions. 

CPU 

Usage OVLjCPU 

0% 0% 

10% 0% 

20% 3% 

30% 5% 

40% 10% 

50% 15% 

60% 20% 

70% 30% 

80% 45% 

90% 65% 

100% 100% 



Figure 4 COPL CPU load level and Its fuzzy equivalent level 



ia.l^ MEMORY (NOM/OOM^ 

The global MEMORY load (in opposition to the process memory occupancy) can be checked using 
standard OS functiorts or UMLA API The returned value is a percentage of the whole MEMORY capadty 
(in a furtiier step, it could be a per-cpu measurement in (^se of multiple CPU or...). Before using this raw 
measurement it can be useful to go tiirough an intemnediate slate, making the MEMORY raw 




measurement correspond to a MEMORY overload level (OVL_ MEM). TMs intermediate statement j$ 
mostly useful if the NOM does not rely on Fu2zy Loglc^ indeed the FL perfbmis automatically such 
converdons. 



MEMORY 
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3% 
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30% 
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25% 


50% 


50% 


60% 


75% 


70% 


90% 


80% 


95% 
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100% 


100% 


100% 
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^ ^ t!^^ ^ c^.^ 



Figure 5 CX)PL Memory tharge level and its Ivzzy equivalent level 



1.1.1^3 I/O(NOM/OOIM0 

The global I/O load (in opposition to the process memory occupancy) can be checked using standard OS 
functions or UMLA API. The returned value is a percentage of the whole I/O caf^dty (in a further step, it 
could t>e a per-cpu measurement in case of multiple CPU or...)- Before using this raw measurement it 
can be useful to go ttirough an intenmediate state, making the I/O raw measurement correspond to a I/O 
overload level (OVLJOS). This infemnediate statement is mostly useful if the NOM does not rely on 
Fuzzy Log^c, indeed the FL perfomns automatically such conversions. 



1/Os 
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Figure 6 COPU l/Os usage level and its fuzzy equivalent level 



1.1.1.2.4 OVERAIiL SYSTEM OVERLOAD O^OM/OOM) 



Being interconnected to other Surpass components that interact with it, the COPL has to get infomnation 
about the whole syst^ health and communicate its own status to the rest of ttie system, if it enters an 
overload status. 




For the LWIP, ft Is important to keep informed about the overall overload situation of fts connected 
neighbors Inside the considered Surpass configuration. Overtoad Status Messages are supposed to be 
sent from the overioaded components to the COPL (belonging in the same way to the overall overload 
control system). 

A kind of priority has to be defined within the IMP in order to react as a slave Inside the overall overtoad 
handling of Surpass. If the central call control enters the overtoad status 6, then ft sends a message to the 
possibly responsible units in order to tell them to reduce the admission of new calls Inside the system. 
This should also work spedaily in the case where the COPL hosts the PCU. The PCU can be at the origin 
of new call attempts. The PCU has to read on some congestion signals coming from the central call 
control system (EWSD CP). The COPL Is notified via overtoad messages from the CP. 

1.1.1^ APPLICATIONS SPECIFIC RESOURCES (OOM only) 

Once the OOM Is reached, it is compulsory to detect which part(s) of the whole system Is (are) 
responsible for the overtoad sftuatlon. To reach this, one needs some applications specific resources 
monitoring. Most of the applications use the same kind of resources. We regroup these ones into five 
main types (similar to the ones in the LTG load control and related to the application configuration file 
wtthln theUMLA): 

> communication blocks, 

> timer blocks, 

> heap blocks (UMLA : queues). 

> memory blocks (UMLA : pools), 

> transaction control blocks; 

These resources can be controlled either by the UMLA and/or the OS. The LMP will then access the 
resources through one of them. The LMP may consider the overall consumption of these resources and 
detemiine the percentile use for each application. These common resources are essential for the well 
funcOonlng of tiie COPL and the extent of their pools is designed to be sufficienL But their availability 
under heavy load must be monitored. This supervision Is not meant to be a means for nicely tuned load 
regulation measures but ft Is an "emergency break". They will be used fbr the determination of the 
appllcation(s) responsible for the overtoad situation. 

I. 1X2.6 Transient Parameters CNOM/OOM) 

These parameters are useful in order to avoid a too rapid reaction against local overtoad situations that 
are not significant and therefore must not start overtoad treatment procedures. It Is still under analysis 
which fonn tiiese parameters will take. The simplest form can be the tracing of tiie time inten^al ^nce 
possible overtoad status entry. The next step is to tune this Interval so that the system stays stable and 
reads only on higher overtoad duration. A second form could be the derivation of the overtoad level over 
the time to detemiine If there is a possible prognostic to do witin its evolution. These options have to be 
tested to detennine which is the most optimal one for the considered scenario. 

II. 1.3 The - NTormal Operation Mode fNOM) 

The NOM is in charge of controlling the (over-) load level during nornial operation. According to the new 
calculated level, it eventually switches to the Overtoad Operation Mode (OOA/I). In orderto make this level 
calculation, the NOM needs the in 1.1.1.2 described inputs (only the system relative ones). Using the 
fuzzy logic descriptive model, it is easy to mix these inputs together and get the overtoad level using a set 
of basic rules. 



Nonnal Operation Mode 




fCOPLiOS Commandos (Solaris) 
COFL OS OAFI-Ftoictlons (Solaris) 
^X>FL- UMLA - Afl OSiemens) 
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Local Overload Level calculation 

- Global Overload Xicvel calculation 
* Overload dedston 



Figure 7: Fuzzy Logic applied to NOM 



1.1.13.1 Overview of fuzzy logic used in NOM 

In NOM, every CHK_TIAAE sec, the predefined resources are checked (through COPL OS/UMLA) and are 
stored for following treatment The next step consists in fuzsdiying these crisp values into fuzzy variables. 
The sequence of fuzzy logic (inference) processing can be broadly divided into two functions: infereru:e 
and defuzzification. The inference process begins mttx the processing of the production rules. Individual 
rules consist of a condiBon block (also called the antec^ent or ""IP block) and a concluston blodc (known 
as the consequent or THEN" block). The inference process proceeds from the conditions to the 
conclusion, and then to the lexical sum. To get a usable output, however, a deffu^er operation must be 
performed to convert the fuzzy values back to a fixed, discrete output vsdue, here the overioad level for 
instance. 

"E CPUJLOAO_VERY^HiGH AND MEMORV LOAD VERY HIGH 

lOSJJOADJ/ERYJHIGH 

THEN OVBRLOADJMVELJ/ERYJiiGH 

wmi HIGHEST PROBABIUTY 

Figure 8: a typical (and very true) rule example 



All traditional logic operators (and, or, not..) are available and also new ones tiiat work only for fuzzy 
logia Collecting such rules is easier than deducing complicated matiiemafical fonmulas that have to be re- 
engineered wKh the introduction of new variables in the system. The rules can be deduced from 
measurements and observations, using a quite str^ghtfonA/ard intuitive deduction. For example, 
experience (thumb rules) In system tuning can be directly reused. 

A first propo^ for the NOM fuzzy model Is done here according to the requirements emitted by ICN WN 
GC SE 3. These requirements impose to tiie NOM to stay platform specific and not application specific. 
That means that only a part of the monitored resources \MII not be taken into account In the NOM fuzzy 
model. These remaining resources are to be used in the OOM anyway. The iuzz^ kernel uses a fuzzy 
model definition file "overtoadjdetecQonjnodel.fuz". 




Figura 9: NOM fuzzy inference engine 



1.1.1,3.2 Fnzzification stage t*. 
A Crisp Input Is a parameter coming from the monitoring system (cpu, memory, los, CP-OVL), it is a 
number comprised in a predefined interval, for 
example for the cpu usage Input parameter, the CPU 
crisp input is defined as a real number between 0 and 
1 {or 0% and 100%). For this crisp input, a fuzzy 
variable has to be defined using "sets" of the fuzzy 
language: 

We define here eleven intensity levels of cpu usage 
(0...10), ranking from 0 to 1 for the crisp input 
parameter For example, the definition of level 3 of cpu 
usage is defined through a trapeze starting by 20% 
climbing to the maximum of vsdidity from 27.5%, 
staying at maximum till 32.5% and decreasing to zero 
by 40%. 

E.g. for an Input cpu usage value of 25%, we say that 
the cpu usage fuzzy set 3 diess/el 3) is true with 65% 
validity. It is also tine case for level 2, that means tiiat, when cpu usage is equal to 25%. CPU is at the 
same time in level 2 and level 3 with 65% validity for each. The graphical representation of the CPU fuzzy 
variable corresponds to a part of the fuzzy model file: 




FigurB 9: fuzzy variabie cpu (sets) 



CPU_0 { XSXARZM) XSTOF^l XLSN^lOl FONC2^XRAPJSZJ9(0. 000, 0.000,0. 025 *0.100«0) 1 

CP0.1 { JCSXARTMt XSTOF-l XLBH^lOl FCZNC3^TRAfiS2S(0.000, 0.075, 0. 125,0.200,0) ) 

CPU_2 { JCSIAROM) XX&l^lOl ftINC2WZRAJP&2£(0. 100, O.!? 5, 0.225, 0.300,0) ) 

CP0_3 I XSTABT^ XSTOP^l XLEI*-101 FaNC3^2AAPB2£(0. 200, 0.275, 0.325,0.400^0) > 

CPU_4 I XSTABT~0 JfSTOP-1 ^fLEN^lOl FDNCT-a!RAPB2B(0. 300, 0.375, 0.425, 0,500,0) ) 

CPI7_5 { XSZART-O XSTOF^X XLBih'lJOl FDNCSwnUlfiB3B( 0.400, 0.475,0.525,0.600,0) ) 

CPO 6 ( JGSXAR3W0 XSTOM, XISI^lOl PCNC2V3RAFBSfi(0. 500,0. 575,0. 625, 0.700,0) | 




CPU 7 { XSXARX-4> XSTOP-1 XtKW-101 FDNCJVERAPSiJBtO. 600, 0. 675, 0.725, 0, 800, 0) J 

CPU 8 { XSiaOr-D XSTOP'I XLBlf'lOl FaNC3V23lAP52B(0. 700,0. 775, 0.825, 0.900,0) 

CPBL9 { XSIflR2M> XSJOP-1 XLEi*-101 F0NC2VIRAPff«B( 0.800, 0.875, 0*925,1.000, 0) > 

CPU_10 1 <XSZaRZ>-0 XSSrOM XZ£W-101 FaNCaVXRAPSZBCO. 900, 0.975, 1.000, 1.000,0) ) 
CVSBXABLS8] 

1 CPU <0,l,2,3,fl,5,6,7, 8,9,l0> X» 

F/gur© Y 0; deflnttlon of the CPU fuzzy variable using fuzzy sets 

Extracting the validity of each ftizzy set for each variat)le according to ite crisp value is called 
"Fuzzification" of the input crisps. 




Figure 1 1: NOM fuzzy variables 
Once all Input crisps have been fuzzifled, the inference process is entered. 
1.1.13.3 Inference process 

The inference process reads the fuzzy rule base and evaluates its contaned rules accorcfing to the f uz^ 
sets coming from the fuzzification stage. These rules look quite similar to stendard logic rules. Ulce we 
described them In Figure 8, the fuzzy rules are build follovving the well-known IF THEN construction. 
Where tine difference between standard (Boolean) logic and fuzzy logic takes place, it is in the values 
teken by the operands and the matiiematica! definition of the operators. Where '*true*' (1) and "false' (0) 
are the only possible values for operands In standard logic, the fuzzy logic allows operands to take 
continuous or discr^e v^ues between 0 and 1 (in its normalized form). Some logical operators are 
defined in the standard logic and also in the fuzzy logic: 
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A characteristic of the fuz^ logic op^ators is the possibility to change their mathematical definition 
according to the context 

A AND B » M]N(A,B) but also A AND B = ALGP(A,B) (algebialc producO 
A OR B = MAX(AB) but also A OR B » ALGS(A,B) (algebraic sum) 
N0TA:=1-A 

According to these definitions, it is understandable how fuzzy logic allows logic with values between 0 
and 1 (and not only 0 or 1). Again the very true rule (Figure 8): 

Lets say that if CPUJ.0ADJVERYJ<IGH = 0.7 (after fuzzfficailon). WlEMORYJjOAD.VERYJilGH » 03, 
tOS_LOADJ/ERY_HlGH = 0.9, 

then the assessment 

IF CPUJJOAD VERY HIGH &ND MEMORY_LOAD_yERYJilGH AND IOSJ.OAOJ/ERYJiiGH THEN 
OVERL0J^^LEVEL_VEf^^HIGHmni HIGHEST PROBABIUTY 

becomes, if we tal<e MIN as AND operator definition. 

OVERLOAD_LEVELjyERY_HIGH is true with 60% (=min(0.7.min(0.5,0.9)) x 1.0) 
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FiguTB 12: output of all the rules within the fuzzy model 



When all rules have been calculated, the 
resulting sets of the output variable have to be 
"accumulated". This is done by composing all 
the sets together using an "accumulation" 
operator, lil<e the logical sum (max operator). 



The result of this operation can be seen in the 
lower part of the Rgure 1 3. One can see that the 
different rules (here only given as example in 
Figure 12) that generate ttie output result 



Figure 13: accumulation of the output 

variable 
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1.1*1*3*4 Deftizzlficalion 

The last step performed by the fuzzy logic kernel within the NOM Is the deffuzification. As we have seen 
in the previous step, the fuzzy logic delivers an output result in form of a graph (Figure 13). This result Is 
not usable In this form, it needs to converted Into a crisp value to be exploitable in the rest of the NOM. 

Again, it 5s possible to use diverse methods or operators to get a crisp value out of the insulting curve. 
Possible operators are the COG (center of gravity), the NIAXWIAX (ma)dmum of ma^dmums). Here we 
propose to use the COG. This operator permits taking Into account all the results of an the rules, where 
the MAXMAX is a pessimistic operator* The COG operator search the center of gravity of the surface 
between zero (y axe) and the resulting curve from the inference step. In our eacample, the COG Is 0.4. 
With MAXMAX we would have got 0.65 Qhis does not take into account the result of some mies, giving 
also a result around 0.2 and 0.4). 

Further investigafions have to be done in order to determine the best-suited operator for the 
deffuzification. 

1*1.1.3.5 COFL Overload level 

The value delivered by the fuzzy logic model of the NOM ranks from 0 to 1; so that if we want to Stay 
compatible with the CpyLTG-Overtoad levels, we must re-scale from £0:1] to I0;1 ;2;3;4;5;6J. 

The fuzzy logic model is designed to run with a flmfted amount of sel^ for a given variable, if we consider 
the output variable COPL^OVL having 7 sets : 0.1^,3,4,5,6, then we can gel the overtoad level by 
fuzzifying the crisp Into sets validity and then take the maximum validity. 

The other method is to re-scale llneaity firom 0:1 to 0;1;2;3;4;5;6. This solution should be taken only In the 
case of cpu resource shortage. Indeed it Is not as efRdent as ttie first soluHon. 



1 -1 .1 .4 The Overload Operation Mode tOOM^ • 
If the NOW detects an overload level superior to a given threshold, it switches to the Overioad Operation 
Mode (COM) in order to determine ttie reactions needed to return to the Nonma! Operation Mode (NOM). 
Within the OOM, measurements are made (resource checking) and combined to detennine which 
process or application has to be reduced, alamied or made aware of the overload situation. 



Ov^load Qperadon Mode 




GOFLOS Commaiidos (Solsris) 
GOPLt OS C-API-Fonctioos ^idaiis) 
COPL ' UMIA - API (Siemens) 



Fnz^ logic based expert system 

Proprietary/commerclfll foiay logic kernel 
Cofitomized finoy logic model 
Local Overload Level calculation 
Global Overioad I^vel calculation 
Application specific expert system 
^ Overload treatment 



Figure 14: Fuzzy Logic applied to OOM 
1.1.1.4.1 Overview of fiizzy logic used in OOM 

The general function of the fuzzy logic in the OOM is similar to the one for the NOM. Only the time 
interval, the variables checked and the output treabnent are different Once the OOM is entered, the time 
Interval between tNO overioad diecks (OVLCHKJTIME) Is smaller than the one used by the NOM 
(GHKjnME). This ensures a quicker return to the NOM if no more overioad is present 

The same fuzzy core functions and Interfaces are used. The fuzzy kernel takes a fuz;^ model definition 
file "ovenoadJtreatmenC«Tf^odel.f uz": 

> the input variables encompass the ones of the NOM and some 
application specific resources, 

> the output variables define again the overioad lev^ for the \whole 
COPL but also application specific overioad levels (degree of action 
to be taken for this particular application), 

> the COPL overioad level is calculated at that step. 

The aim of the fuzzy logic in the OOM is to determine a level of overioad or respon^biRty for overload per 
appiication/pTocess and also the COPL overioad level again. The application/process overioad levels will 
be further used by the Overioad Treatment Process (OTP). 



We can see in the following figure the fuzzy Inference engine used fbr the OOM: 




Figure IS: OOM fuzzy inference engine 

After the inference Process step, it is possit>ie to 
extract rules validity as shown in 

Figure 16. 

These values (or a part of them) will be 
transmitted to tiie OTP for further treatment It is 
not the usual step that is used for a fuz^ logic 
expert system. But during the study it appeared 
to be a good solution to help the OTP program to 
take some decisions. This rules validity is kept in 
order to be mixed wfth the results coming from 
the defuzztfl(»tion step. 



13946670 OfDIIiai* 141018 17 18l«3Dai2t»M2BSS3ra8aBaDataStt>l 



Rgure 16: output of all the rules vwthin the fuzzy 
model 



LlAAJi. COPL Overload level 
Same as 1.1.1.3.5 ... 

Open issue: shall we use the results of the application specific overioad calculation by calculating the 
COPL overioad level at that step or shall we re-use the NOM fuzzy mod^ to control again the resources. 
Further investigations must be made 



Application/process spedfic overload level 
Each application/process that runs on the COPL needs three blocks to be integrated into the Overioad 
Management Sy^m: 

- dedicated routines to check its specific resources status^ 
an associated fuzzy logic variable (definition of sets). 

- a set of rules leading from these resources to a specific overload level. 



Depending on the chosen programming technique, these blocks can be Integrated dther offline or online 
(database). This issue is op&n and is not in the scope of this document 

1 .2 Overload Treatment 

After the Overload Detection, Overload Treatment has to be started in order to come t^ck to a non- 
overloaded situatioa The Overload Detection and its associated components deliver a COPL Overload 
Level, application/process specific Overtoad Levels and overtoad rules validity values to the Overload 
Treatment (OT) program. 

According to these inputs, the OT has to dedde acBons to be taken in order to bring the back to 

its normal status. To do this, the OT has to start actions locally (wtthfn the COPL) and/or remotely by 
sending overload messages to the connected equipment 

AD actions taken locally belong to the Local COPL Overload Treatment (1.2.1). The other actions depend 
on the communic^on of the COPL Overtoad Level to the other platforms (1 .2.2). 

Local COPL Overload Treatment 

The Local COPL Overload Treatment is in charge of taking actions to reduce overload locally on the 
COPL itself and commurucating its overload status to oO^er connected platfbnfns to first avoid new 
incoming traffic and second inform the system. 

1 .2. 1 . 1 Overload Treatment Process (OTP^ 

The Overtoad Treatment Process and its sub^stems drive all these features. Four types of mechanisms 
participate to the OTP: 

1 . Decision of the actions to be taken, 

2. Active or direct local overtoad reduction, 

3. Passive or indirect local overtoad reduction, 

4. Pas^e or indirect rmiote overtoad reduction. 



Mechanism 1 and 2 take place In the Overtoad Treatment Reduction Process. Mechanisms 2 and 3 take 
place in the Overtoad Treatment Communication Pnscess (external and internal stages). 




Figure 17: the Overload Treatment Process in the COPL 



1:2.1.1.1 OveiioadlteatmeatBedoctioii Process (OTRP) 

1.2-1.1.1.1 Overload treatment id^ntificatioa 

This process first decides which acHons (and action types) have to be tal^n accorciing to the diverse 
overload levels and rules validity it becomes finom the Load Monitoring Process (LMP). We mean actions 
here as active or passive, local or remote, increasing or decreasing. 

- AcBve acflon: action that acts directly through the OS or the UMLA on 
applications, 

- Passive action: action that acts indirectly through a common interface 
(thresholds in a seif-controlled -^ndalone- application), 

- Local action: action acts local on the COPL, 

- Remote action: action sends messages through interfaces to extemal 
platfomis/process, * 

" Increasing action: action aflovk^ more resource consumption, 

- Decreasing action: action restricts resource consumption. 



Then the OTRP starts the needed overload treatment mechanisms. The OTRP treats Itseif the local 
active actions and delegates all the other actions to the Overload Treatment Communication Process 
(OTCP). 

The reason of ttils separation between OTRP and OTCP is that local active actions distinguish 
themselves from other ones by their mechanisms; they do not communicate with the concerned 
application/process but act direcOy on it through the OS or the UMLA (for example by reducing the 
allowed amount of cpu time or memory or blocking their communication with the network communication 
stacks). 

The OTCP communicates either locally with COPL hosted appllc^ons/iprocesses using messages and/or 
threshold variables or remotely with other platfomns and applications using the messaging system. 

1.2,1.1,1,2 Iptenaal Strategic of Load Rejection andRedactiaii 

The fuzzy logic expert system of the OTP enables dasses of services/processes to be defined. This 
means that different priorities can be given to the applications/processes running for the COPL. 

L2.LLL2J LoadReducdon 

Internal strategies of load reduction are in that case strategies of attribution (or distributioji) of resources 
to appHcations/processes according to their overioad status and their pre-^lefined priorities. 

CPU» MEMORY and lOS are shared by these applications/processes. It Is possible to change the 
repartition or attributed amounts of these resources for each application through either the OS or the 
UMi.A. If the action takes place without alerting the application with messages, then R belongs to the 
OTRP, if messages are sent, then It belongs to the OTCP. 

If a given application/process has reached a critical overioad level and other applications have been given 
amounts of resources they do not use at that precise time, then a good strategy Is to give these resources 
to the overioaded application/process so that it can accomplish its task and return to a nomnai load 
situation. As soon as this Is done, the re-routed resources can be given back to their owners. 

That means that in overioad status, a dynamic resource sharing can be achieved, and that the repartition 
is done by the fuzzy logic e^ert system. 

L2. L L J. 2,2 Load Refection 

internal strategies can also include load rejection actions. These is done by disabling the upcoming 
service requests. These strategies have to be identified in the next parts of this document (application by 
application). 

If the load rejection action takes place in the COPL without alerting the application with messages, then it 
belongs to the OTRP, if messages are sent, then it belongs to the OTCP. 

Overload Treatment Communication Process (OTCP) 
This process is in charge of relaying the overioad treatment actions (decided in the OTRP) to local or 
remote applications/processes/equipment using system messages. These messages can be sent using 
the UMLA and/or other communication protocols, depending on the destination. 



The appHcafions/processes addressed by the OTCP can be of two types, local or remote. Local means 
here that they run directly on the COPL Itself and remote means that they mn on some separate 
equipment and can be commanded through some management protocols. 

1 2-1.1^.1 r«nntniifM«tHTip[ OverlQad Level to COPL Applications . , ^ ^ ^ 

There is an a(^e way of inforniing applications about changes of the overload level by event and a 
procedural Inteifece that makes the oveiload levels available. 

The e>®ct mechanism (message type, interface and procedure) has to be defined for each application or 
process. The dhrersHy of applications, processes and their manufacturer does not allow a common 
treatment That Is the reason why the overload treatment has to be federate Into a single control system 
thattiien deddes and distributes overtoad rejection/reduction actions. 

Possible means to adiieve the communication of the overioad levels and actions to the applications and 
processes are: 

- messaging interface, 
. UMLAAPI, 

- Open Third Party APIs, 

- Network Management Protocols (SNNIP.. 

All these options will be discussed in dedicated paragraphs for the OSP and the PCU. 
1JZ.2 Communicating Overload Lievdl to Other Platforms 

For several load control related purposes load levels need to be distributed by COPL load control to 
others but the own platform. 

Possible means to adileve *e communication of the overload levels and actions to the applications and 
procjssses are: 

- messaging Interface 0-TG, EWSD, Proxies), 

- Network Itfanagement Protocols (SNMP...). 



1,2.3 Applications Overload Treatment 

Each time possible, the applications should have a Wnd of integrated Call Admission Control that checks 
the last known overioad status. 

This overload status can be different for each application, forcing it to react differently against the load 
situation. This allows a higher fle)dbillty for the overload treatment mechanisms. 

Depending on the inter-process communication capabilfties of the considered apptication, its dedicated 
overload status will be delivered to it (OTP/OTRP or OTCP) or will be available for polling from the OTP 
(OTCP). 

According to its overload level, the application can drive different strategies, like delaying or refusing new 
Incoming requests. 

The new Incoming requests should be stopped, when possible, not in the application itself, but In the 
processes that are at the beginning of the call/request processing. But, if these processes are used from 
other applications that are not In an overload situation requiring some overioad treatment, then the new 
Incoming requests have to t^e stopped at the next level, after leaving these processes and before arriving 
at the considered application. This is done by configuring the fuzzy expert system with the conrect set of 
rules. 



Example: 

For the CtD application, new incoming requests should be stopped already within the PINT+ GW 
Application by setting the overload level of the PII^+ QW Application high enough to stop processing of 
new Incoming requests. 




If the PINT+ GW Appficafion is shared by other applications than the CtD application and these 
applications have a higher service priority level, then the oveiload level of the CtD application shall be set 
so that ft does not authorize new sessions and the PINT-i- GW application shall stay as before. 

Concretely, If the NOM detects an overload situation, it enters the OOM, The OOM then tests the 
overload status of the CtD application and the PINT+ GW application. If the CtD application Is the only 
connected application to the PllsTT-i- GW (see Rule 1), then the PINT-t- GW application gets a higher 
overload level and starts rejecting new incoming requests, if the CtD application shares the PINT**- GW 
with otiter applications having a higher priority level (see Rule 2), then it becomes itself a higher overioad 
level and starts itself rejecting new session attempts. 

It can be translated into two fuz^ logic rules: 



Rule1: 

IF OSP_OVERLOAD_HlGH 
AND CTD.ACTIVE_SESS10NS.H1GH 
AND fNOT PINT+GWJSHARE_HIGHi 
THEN P1NT+GWJ0VERL0AD_LEVEU_HIGH 



Rule 2: 

IE OSPjOVERLOAD_HIGH 
AND CTD.ACTIVE_SESSIONS_HlGH 
AND PINT+GW.SHAREJHIGH 
THEN CTD_OVERLOAD_LEVEL_HlGH 



4. Advantage of tiie invention 

Here we develop control mechanisms and policies such fliat the COPL CO tracks and avdds non-manageable overload 
situations before they set in (predictive fuzzy logic rules in the NOM), CO avoids also short ov^load picks (trmsient &zzy 
logic rules in the NOM), and (iii) provides sorvice differentiation between different ^pHcations based on specified pohcies 
(application spedfic fbzzy logic rules in fee OOM). 

With such support a saver becomes self-suf&dent in preventing overload and can (ft^namicaDy configure flie coi^l 
medianisms provided to obtam the desired perfiarmance effects. One of tiiie advantages of this approadi is that no additiaoal or 
new equipment needs to be deployed separately to provide similar capabilities. 

Further, this permits ©dsting server in^allations to be upgraded m an plication and network txanspareit mann», Le. , witiiout 
deeply modiftring applications or existing network connectivity* 

Another significant advantage is that the control settings provided can be used to track an overload situation as it unfolds, 
aerating notifications or control acticais as necessary. This greatiy simplifies administration and capacity plannmg ftnr a 
server, and by extension for a server feim, thoreby reducing system management costs and complexity. This is also applicable 
to proxies, front-end servexis, ... 

The provided fiazzy logic programming language aafiiarizes all levels needed ftnr a predse tuning of the overload handling. 
Ihere is no limit lor fiie granularity of the overload dedsion and overload treatment models. 

Furthermore, &e idea to use tiie results of the rules calculation in combination with the output variables calculation allows a 
sunple desaription of overload actions to be spedally taken. Because a rule describes a precise mfac of overload conditions like 
common resources ov^ow, application spedfic queues ovwflow, fids same rule can be taken as decision base for ov^load 
handling actions. Every new recognized overload situation can be introduced in the fiizzy logic expert system database and 
actions can be taken according to it 

The proposed fiizzy logic toolbox allows giving diflferent priorities to the rules used for the overload status calculation. Ihis 
permits difierent levels of predsion in flie overload calculation. More important rules get a higher priority &sAoc. 

The proposed fii22y Ip^c toolbox also allows also dynandc chai^ges. That means, it is posdble to couple it to sdf-leaming 
medianisms like neuronal networks in order to develop a sdf-ad^ve overload control expert system. 



5. Exan:q)l6(s) of the invention. 

> Intelligent Load Control for fiie OSP/PCU/ESUN in SURPASS 

> Intelligent Load Control for Web-ServOT 

> Centralized differentiated QoS aware Call Admission Control for new Soft-switdies. 
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1 • Documents describing ibe CoPl / UMLA 

2 



rB0262] 


P30308-A7850-A262-06-76J2 

B0262: Commercial Platform For SURPASS 


[B0356a] 


new for EWSD V16 / hlQ9200 V5 

BO 356a: CoPI Carrier Grade Part 1 (HW/ SW maintenance) 
Team leader Dr. JQrgen Welter 


[B0356b] 


P30310-A2561 -A018-**-76J2 

BO 356b: OA&M for Carrier Grade CoPI 


[B0357] 


P30309^1493-A357-**-76J2 

B0357: High Perfomiance Interface CoPI - SSURPASS Core 


[BO360] 


P30308-A7850-A360-**-76J2 

BO360 - Evaluation RTP, SUN-Cluster 3.0 / SantaFe 


[CoPLDEV] 


P303O9-AO648-A00O-*»-7618 
Commercial Platform Developers Guide 


[CoPLREF] 


P30309-A0648-A1 00-**-761 8 

Commercial Platform Users Reference Guide 


[OpCon] 


OpCon User (Manual; available at ICN WN CC EB A1 1 


COM] 


P30308-A9791tA003-**-7618 
CM-Plan for Commercial Platform 


[B0262] 


P30308-A7850-A262-**-76J2 
Commercial Platform for SURPASS 



3 • Docaments describing VOS/VxWorks/MGI 

4 



[N/^orks] 


VxWorks 5.4 

httD:/AAAAAW,windriver.OTm/Droducts/html/vxw^ 


[VxWorks_ds] 


V)AWorks 5.4 Datasheet 

download from httpi/AftnAW.windiiver.com/pdfAocworksKls.pdf 


[N/xWorksjguide] 


VxWorks 5.4 Programmer's Guide 

do\Amload from http://www.windriver.com/pdf/vxworksjguide.pdf 


[VOSJ 


P30NNN-ANNNN-ANNN-XX-001 8 

Virtual Operating System (VOS) [available on server mentioned above 
or in ClearCase for project INTERNODE] 


[OCANEQ] 


P30308-A8067.A014-**-0059 (in Gemian) 

OCANEQ Stufe 3: DIR. AUFSPR., 64 KANALE, BACKUP FUNKT. 


[Route98] 


Route98 user manual 
Available at PSE EZE CN3 



5 • Documents on VoA and US based PCU; please le&r also to IMS enbyfiur BO 380: 

6 ltttps-7flms.i<gLaanens.deyihrelin1<^»ivelinWQpgi/234837870 
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[BO3801 


P30oU9-'A 1 / y U-Aoou- - / QJ^ 

BO380: MGC for ATM MG in WWi 


ICFS_R18] 


Call Feature Server (hiQ9200) for Voice over ATM (VoA) U. S. Release 
18.0 


[CFS_R011 


P3031 0-A256 1 -Q000-**-76J2 

Voice over Packet (VoP) Virtual Trunking (hiQ9100) 


[PCU.VOA] 


P30310-A2561-A018-**-7659 

PCU Voice over ATM Appiication (Release 1.0) 


Variras DocaniBiils , 


[B0213b] 


P30309-A1 632-B213-**-76J2 
MGC MGC Communication 


[MsgLCat] 


P30310-A2796-Q001-**-7622 

Message Catelogue: hiQ Platfomd Interfaces 


[B0385] 


P30309-A1561-A385---76J2 
Reuse of SURPASS IVR for EWSD 



[EN 300 403-1] 


ETSI BN 300 403-1 Vl.3^ (1998-04) 
Ciiropcan stHanosni i cxeconuiiiujucaiiQiis sroes^ 
Integrated Services Digital Network (ISD]SO; 

Digital Siil>srfib^T Signalling fiystem No. one (DSSl) protoodl; Signaning uetwod: layer 
for dxcoit-mocle basic call contiol; 
Part 1: Pxotocol spedfication 

ITrU-TRecominendalionQ.931 (1993), modified] 


IEN300 196-1] 


European Telecommiuiications Standards lostitate 
EN 300 196-1 Vl.2.2 (1998-04) 
European Standard (Tdeconimunications series) 
Integrated Services Digital Network (ISDN); 

Generic functional protocol for the support of siqyplementary ssrvice^ Digital Subsaiber 
Signaling System No. one CE>SS1) protocol; 
Part 1: Protocol specification 


tQ.931] 


mJ-TRec<HnmcndationQ.931 (05/98) 
Digital subscribe Signalling System No. 1 

ISDN user-netwoik rotarface layer 3 specification for baac call oontxol 


tQ.9321 


nU-T Recommendation Q.932 (05/98) 

Digital subscribe ^gnalling System No. I 

Generic procedures fi)r the control of ISDN siqiplementaxy services 


PL2251 


rrU-T Recommendation H.225.0 (02/98) 

Call ffjgnaiiing protocols and media i^ieam pad^etizadon &r packet-based multimedia 
commimication systems 


PL2351 


rrU-TRecommendationI1235 (02/98) 

Security and ^Gi3^tion for H-Senes 09.323 and other H.245-based) mnltimedia 

terminals 


IH.2451 


nTJ-TRecommendalionIL245 (09/98) 
Control protocol for multimedia corrmuinication 


IH.3231 


rrU-T ReconunendationBL323 (02/98) 
Packet-based mnWT"^^^'^^ communications systems 


(MGCP] 


BBTF RFC 2705 

Media Gateway Control Pxotocol 
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Stmdardizcftion 



ETSmPH 



Miber2 



ETSI TIPHON project TS-IOIS 13 

Tiphon network architectures and reference configurations 
Phase 2: Scenario I + Scenario 2 



(01/99) 



Pioc. SFIEFhotonicsEast Conf. 'Teifi)niiaxice and Control of Netwodc Systems IIT, (1999) 
Boston, MA» USA» J. F^iber, S. Bodamer, J.C^iaizinskU 
Statistical evaluation and modelling of Internet tUal-^p trcffic 



lETFMBG Draft IETF working group MEGACO 
Media Gateway Control 

draf t-ietf-megaco-protocol-Ol.txi; 
lEEFSIG Draft IETF woddng group SIGTRAN 
Signaling Transport 



rrUTH225 mJ-T Recommendation (02/98) 

H.225 — CaU signalling protocols and media stream padoeWsaUon for packet based 

multimedia communication systems 

nTJm245 rrU-T Recommendation (02/98) 

H.24S - Control protocol for multimedia communication 

ITUTH24S rrU-T Recommendation (08/99) 

Draft K248 - Gateway Control Protocol 

ITUTH323 rrU-T Recommendation (02/98) 

H.323 — Packet-iased multimedia communications systems 

Tn3TH341 rrU-T Recommendation (05/99) 

Draft H.341 -^Multimedia Management Information Base 
rrUTQ543 ITU-T Recommendation 

Q.543 - Digital Exchange Performance Objectives 



Paxonl IEEE/ACM Transactions on Nctwoddng (06/95) 
Vem Faxon and Salfy Flayd^ Wide Area Traffic: The Failure ofPoisson Modeling 
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SIEM01 
SIEM02 
SIEM03 
SIEM04 

SIEM05 
SIEM06 



S3EM07 

SIEMOS 
SIEM09 
SIEMIO 

SIEMll 



SIEM12 
SIEM13 

SIEM14 

SIEM15 



Commercial Platfimn for SURPASS 
Business Opportunity Specification 
Document P3030S-A7850-A262-06-76J2 



Improved Access to Voice aver Internet 
Document P30308-A8261-AOOO-**-76J2 
F-Spec-L2: 

Intemode Step 2: SWfor integrated NB:PoP 
Docnment: P30308.A0027-A122-**-7659 
F.Spec-L2 

EWSD Intemode SLM[:PHA 

Packet Hub: Hardware and Basic Firmware 

Document: P30308-A9054-A000-**-7659 

Functional SpeciftcaUon 

EWSD Intemode step I: ISS 

P30308-A0041-A342-**-7659 

Func tional Specification Level 2 (LM27100) 

EWSD IrUemode Step 2 

Smi'MPB 

Modem Pool Card 

HWandFW 

P30308-A0027-A100-**-7659 
Functional Spedflc^tion Level 2 
EWSD Intemode Step 2.2 
ENMV4 

P303O9-A0125-AO0O-**-7659 

Functional Specification Level 2 (LM27106) 

EWSD Intemode Step 2 SW Prereqmsites 

P30308-A3333-V013»**-7659 
Functional Spedfication Level 2 (LM27106) 
EWSD Intemode Step 2 SW Prerequisites. Part 2 

P30308-A3332-V013-**-7659 
Functional Specxfication Level 2 
LM 27108 

SW for hi^ Bitrate P6P 
P30308-A0027-A108-**-7659 
Functional Specification Level 2 
EWSD Intemode 
SIMI:PHA 
Packet Hub PHUB 
Remote Access Server (FtAS) FW 
P30308-A9055-A000-**-7659 
BOS Concept Paper 
loteinet Scqiplementaxy Services 
P30308-A8262.AOOO-**-76I2 
Functional Specification Level 2 
LM2S102 

Impioved Access to VoIP (EAVblP) 
P30308-A0028-A102.**-7659 
Functional Specification Level 2 
m 28185 

Internet Subscnber Controlled Inpot 
P30308-A0028.Al85-**-7659 
Functional Specification Level 2 



V14A 



Level 



2 

POP' 



V13A 
V13A 
V14A 



V13A 



V14A 



V13A 
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General Information 



siem;i6 

SIEM17 
Wiffil 



MWI 

M^sage Waiting Indicatioii aocording BTSI 
P30308.A8560-A013.**-7659 

FimctiQnalSpe(nficadonLevel2 V14A 
LM 40166 
Click to Dial 

P30308rA0040-A166-**-7659 
Handbook Load Control Mecbanisms 
P303O8-A8387-AO00-O1-7618 



Department of Computer Science, University of Saskatchewan (03/96) 
Carey L. Williamson et ai, Web Server Workload Characterization: The Search for 
Invariants 

Umverstty of Saskatchewan (04/97) 
Carey Williamson et al. Statistical Multiplexing ofSelfiSimiUo' Trqffic: Theoretical 
and Simulation Results 
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General Information 

1 /U2/ Message Catalog 

2 P30310-A2568-QA001-**-7622 

3 HiQ LAN Interface 

4 HttQ/CoPlIntsrjEace 

5 ^ . 

6 /I13/ Design Specification 

7 P30310-A2668-A018-**-76D8 

8 Subsystem JCILD 

9 O^PlIntei&iceLoadDistnbiitor 

10 ^ . 

11 /n4/ Design specification 

Safeguarding MB, Subsystem JSGMB 

13 Process SWABO 

14 AsofEWSDV13 

15 P30303.D0863-A604-**-76D8 

16 

17 ai5/ Design Specification 

Safeguarding MB, Subsystem JSCa^B . 

19 Component: Configuration MB 

20 V13T 

21 P30303-D0977-T013-**-76D8 

22 

23 ni6/ Design Specification 

24 Safeguarding Software in the CP 

25 Subsystems JSGMB and JSGMC 

26 Comp onent: Routine Test for Periphaal Units 

27 EWSD V15 and hi^ier 

28 P30303-D0982-V015-**-76D8 

29 

30 /I17/ Design Specification 

31 Sut>system BC 

32 P30308-A0545-A01 8-**-76D8 

33 EWSD Release 1 8.0 
34 

35 /I18/ Design Specification 

36 Sute^stem CO 

37 P30308-A2671-A1 05-**-76D8 

38 EWSD Release 17.0 
39 

40 7119/ Design Speclficaton 

41 Subsystem JAEXD 

42 P30310-A236S-A017-**-76D8 

43 EWSD Release 17.0 
44 

45 7120/ Design Spedficatlon 

46 Subsystem OA 

47 P3031 0-A2669-A01 9-**-76D8 
4S EWSD Release 19.0 

49 

50 7121/ Design Specification 

51 Subsystem JSGLT 

52 P30303-D0980-R01 7-**-76D8 

53 EWSD Release 1 7.0 
54 

55 7122/ Design Specification , ^ , _ ^ 

56 EWSD Safeguarding Software In the CP. Penpheral Safeguarding 

57 Fault Analysis, Subsystem JSGMC 

58 P30303-D0864-T01 3-**-76D8 

59 
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1 7123/ Safeguarding Software in the CP 

2 Safeguarding Software of the Call-Processing Periphery 

3 Subsystems JSGMB and JSGMC 

4 P30303-D0982.V01 5.**-76D8 
5 

6 7124/ CS7U: Adaptation of US Release 18 Software 

7 Functional Specification Level 2 

8 P30308-A7820.Q619-**-7659 
9 

10 /I2S/ Voice over Packet (VoP) 

11 Virtual Trunking (hjQ91 GO) 

12 Functional Spedfication Level 1 

13 P30310-A2561.Q000-**-76J2 

14 nil Hequirement Spedfication 

15 P30310-A2534-A000-**-7626 

16 Media Gateway ATWTDM 
17 

18 lYU Ftoctioiial SpedficatiGn (Level 1) 

19 P30310-A2561-A018-**-76J2 

20 Can Featare Server for Voioe over ATM (VoA) 
21 

22 /D/ Inter&ce Spedfication 

23 P303 10-A2621-A000-**-7618 

24 Media Gateway Controlier / Media C^Eteway VoA Intei&ce Specificatioti 
25 

26 IIAI Message Catalog 

27 P303 10-A2568-A018-**-7622 

28 EWSD/PCUIntet&ce 
29 

30 nSI Functional Speaficatiion (Level 2) 

31 P30310-A2644-A018-**-7659 

32 Vo ATM LTG, LTXJ, Trunk Administration 

33 1161 Functional Specification G^^evel 2) 

34 P30310-AXXXX-A018-**-7659 

35 SURPASS Maintenance 
36 

37 mi Foncdonal Spedfication (Level 2) 

38 P30310-A3100-A018-**-7659 

39 CoPl Interconnection Maintenance 
40 

41 

42 IW Functional Specification (Level 2) 

43 P30310-AXXXX-A018-**-7659 

44 VOATMPCU 
45 



46 nSI Functional Spedficatian (Levd 2) 

47 P30310-A2643-A018-**-7659 

48 Media Control User and C2all Control loter&ce 
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1 



2 2L3 Glossary and Abbreviations 

3 23.1 Glossary 

4 Overload Handling means the sum of all measures for monitoring the load situation of a given 

5 system, detecting different overioad levels and bringing overload treabnent in 

6 action. 

7 Overload Detection means the detec^on of a given level of overload in contrast to normal Operation 

8 State. 

9 Overload Treatment means the sum of measures to get in acBon when a given overload levei has 

10 been detected in order to reduce the system load and therefore the overioad level 

11 with the final aim to bring the system back to nomnal operation. 

12 Fuzzy Logic A type of logic that recognizes more than simple true and false values. With fuzzy 

13 logic, propositions can be represented with degrees of truthfulness and 

14 falsehood. 

15 Fuzzy logic is a superset of conventional (Boolean) logic that has been extended 

16 to handle the concept of partial truth - truth values between "completely true** and 

17 "completely false'', ft is a multi-valued logic that allows Intenmediate values to be 
Ig defined between conventional evaluaSons like tall/shoit*. 'hot/cold' etc. Fuzzy 

19 logic aDows notions Wke *rather warm' or 'pretty cold' to be formulated 

20 mathematically and processed by computers. 

21 For example, the statement, today Is sunny, might be 100% true if there are no 

22 clouds, 80% true if there are a few clouds, 50% true- if it's ha^ and 0% true if it 

23 rains all day. 

24 Fuzzy logic has proved to be particulariy useful in expert system and other 

25 artifidal inteDlgence applications. 

26 Fuzzy control replaces the role of mathematical model with a fuzzy model that 

27 uses expert Icnowledge to describe a system. 

28 Fuzzy Expert System A fuzzy expert system Is an expert system that uses fuzzy logic Instead of 

29 Boolean logic, in other words, a fuzzy expert system is a collection of 

30 membership functions and rules that are used to reason about data. Unlike 

31 conventional expert systems, which are mainly symbolic reasoning engines, fuzzy 

32 expert systems are oriented toward numerical processing. 

33 Fuzzy SetA/ariabie in classical set theory, an element u is a member of a set if it has a membership 

34 value of 1 or is not a member if ifs membership value is 0, i.e. u is either a 

35 member of the set or not In fuzzy set theory, the degree of belonging of the 

36 element u to a fixzz^ set is a real number t>etween 0 (zero) and 1 (one). The 

37 value zero is used to represent complete non-membership, the value one is used 

38 to represent complete membership, and values in between are used to represent 

39 intermediate degrees of membership. In set theory, a fuzzy variable Is the fuzzy 

40 representation of a crisp variable using a fuzzy set 

41 Load A normal txaf&c tate» wMch cortdates to the en^^^ 
42 

43 Load B maximum traffic, whidi can be served without overioad treatment 
44 

45 Message Class Generic classification of the messages monitored for the overioad 

46 handling. The classification is done by the application calling the LOH. 

47 Using the Message classes instead of the Message type themselves 

48 allows a generic implementation of the LOH. 

49 

50 Overioad Class Classification of the required overioad levels (or Load Level - LL) that 

51 have to be considered for the Overioad handling. 

52 
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UMLA 



The Unified ly/lediation Layer, UMLA, is an entity tliat defines a set of 
interfaces available to tfie application programs. ITiis interfaces are 
supplied by the commercial products (OS, DB, FS, etc.) and can be also 
extended by proprietary additions (e.g. communication irtterfeces to 
EWSD platforms). 

The purpose and most important tasic of UMLA is to ensure the openness 
ofttieOSUN. 
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Open The CoPi is open in several respects: 

It employs commerdal HW and SW technology to provide the platfonm. 

The UMLA ensures tiiat it is possible the make use of advances in HW 
(perfonnance, new I/O) and SW (new OS features, stacl^, encryption) 
technology without jeopardizing already developed application SW. Even 
a switch from one vendor to anoti^er must be possible. 

The UMLA must ensure that the CoPi provides an industry standard 
runtime environment Thisnmeans, it must be possible to incorporate SW 
from ISVs. 

The CoPI will become the platform to open SURPASS and B/VSD 
towards fliird party SW development It is not the runtime environment for 
this SW, it rattier provides access to the offered interfaces. 

Operator Mathematical fuzzy operator like AND, OR, MAXMAX, COG 

Node A node Is a complete computing unit consisting of a computer HW, usually 

an n-way SMP, OS, l/O-interfaces, disk. Actually, a node is a server. 

Cluster A Cluster is a collection of nodes, which are connected with each other. A 

specffic SW unit called cluster SW, is responsible for logically connecting 
the nodes and providing certain services to the application SW in order to 
utilize tiie cluster. The cluster. SW also provides the duster management 
functions. 

Cluster Interconnect The cluster interconnect represent the physical interconnections of tiie 

nodes of a cluster. This is its only purpose, no otiier I/O runs through this 
network, except for messages exchanged between the nodes. 



External Storage 



Public LMi 



Sender 



Part of tiie OSUN. used as mass data and file storage device. It is not tiie 
boot device of tiie OSUN, but stores data relevant for bringing up the 
application, e.g. data services, file sen/ices. 

W\Vn public LAN we mean the interface of the OSUN to the IP-network. 
The Public LAN is in ttie domain of the OSUN, which is connected to a 
WAN by means of routers. The WAN is In the telecom or ISP provider's 
premises. 

HW and SW providing a service, which is accessible for clients through a 
data network 
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1 Converged Service: Converged services are provided by Siemens AG on the OSUN, 

2 Converged services provide internetworking support functions betwe^ 

3 the PSTN/ISDN and the IP network to Telcos. Converged services are 

4 building blocks for Telcos to offer converged multimedia applications to 

5 ttieir end-customers. 

6 

7 Converged Multimedia Application: Converged multimedia applications are offered by Telcos to 

8 their end-customers. They are realized on top of tiie converged services 

9 provided on the OSUN and additional front-end (e.g. WEB pages) and 

10 backend services (e.g. databases). Converged multimedia applications 

11 are using simultaneously tine PSTN/ISDN and the IP-network. In this 

12 document converged multimedia applications are shortly called also 

13 "converged application". 

14 

15 Online Patching Incorporation of corrections into the software on a ainning system, without 

16 taking any software or hardware components of tine system temporarily 

17 out of service, and with negligible degradation of service. This could e.g. 

18 be accomplished on a Solaris system by replacing dynamic executables 

19 or shared objects on disk, and then having the runtime linker relink them 

20 at the next call 

21 

22 screen level integration: Integration of various manufacturer specific applications on one screen. 

23 The presentation of each application is done in an own window. The 

24 syntax and semantic of the manufacturer specific application remains 

25 unchanged. 

26 E)«mples for screen level Integration are: 

27 Telnet session for remote temiinal connection (should only be fallback solution) 

28 X-termlnal emulation for remote presentation of a windowed GUI 

29 Http interface using an Intemet browser 

30 NT client containing a management application via CITRIX meta-frame 
31 

32 Basic OAM task: Sequence of SNMP requests, which are peri'ormed one after another The 

33 sequence appears to the operator as a single task on command leveL 

34 2.3.2 Abbreviations 

35 



36 


a 




49 


BCF 


Bearer Control Function 


37 


AAL 


ATM Adaptation Layer 


50 


BCS 


Block Check Sequence 


38 


ADF 




51 


BCT 


Bask} Craft Terminal 


39 


AU 


Alann Une Interfacd 


52 


BlCC 


Bearer independent Call Control 


40 


AN 


Access Network 


53 


B-ISUP 


Broadband ISDN User Part 


41 


AP 




54 


BO 


Bu^ness Opportunity 


42 


API 


AppBcatlon ProgrammeFS Interfooe 


55 


BS 


Billing System 


43 


ATM 


Asynchronous Transfer Mode 


56 


BSD 


Basic System OefirWon 


44 


b 




57 


BW 


Bandwidth 


45 


BAP 


Base Processor 


58 


c 




46 


|C 


Bearer CapabBity 


59 


CAD 


Callprocessing Administration 


47 


BOCH 


Broadcast Control Channel 


60 


CAM 


Can Processing Maintenance 


48 


BCP 

1 


Blnaiy Coded Decimal 


61 


CAP 


Can Processor 
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1 


C6R 


Constant Bit Rate 


2 


CC 


CaQ Control 


3 


CCF 


Call Control FuncUon 


4 


ccnr 


(tamer ns.nx& of ITl UTl 


5 


CCNC 


Com. Channel sfanalnia Network Confand f ElUVSD) 


5 


ecu 


Channel Codec \Jntt 

WI mill Id ww**ow Willi 


7 


CDR 


Charolna Data Reeorrf 


3 


CQP 


^larnlna Gateuvav Prafnftnl 




CIC 


Circuit Identincstion Code 


10 


CID 


(unique) Charging ID 


11 


CIO 


Channel IdenWer 


12 


CIH 


CID Handler 


13 


CIP 


Congestion Indication Primitive 


14 


CR-RIX 





15 CM Connection Mairagement 

16 CN Core Network 

17 CO Connection Oriented 

18 CODEC Coder/Decoder 

19 COH Connection Handler 

20 CONNTRAC ConneoUon Tracer 

21 CoPI 

22 CP Co-ordination Processor 

23 CPl^OVL. . 

24 CPU 3 Central Processor 

25 CPCI Compact Peripheral Component Interconnect 

26 CPM . ConununlcaHon Processor Module 

27 CPU 

28 CRISP 

29 CS CIrouft Switch 

30 CS Coding Scheme 

31 CSE CAMEL Service Environment 

32 CSS 

33 CT Craft Terminal 

34 CTD 

35 CWl 

36 d 

37 DB database 

38 DBMS database management system 

39 DBLU DBMS less unit 

40 DCSieoODlgltal CeDidar System 

41 DL DownUrric 

42 DLU Digital Line Unit 

43 DPC destination point code 

44 DSN Domain Name Server 

45 DSS Digital Subscriber Signaling 

46 DTAP Direct Transfer AppHcaUon Part 



47 DTE 

48 E 

49 EC 

50 EDGE 

51 EFR 

52 EIA 

53 EIR 

54 EMC 

55 Eri 

56 ESU 

57 ESUN 

58 ETH 

59 ETSI 

60 Institute 



Data Terminal Equipment 
Emergency Call 

Enhanced Data Rates for GSM Evolution 

Enhanced FuQ Rate 

electrical engineers assotiation 

Equipment Identification Register 

Emergency Call 

Eriang 



External Service Unit - . 

Ethemet 

European Telecommunications 



Standards 



61 EWI 

62 EWSD ElektronlschesWShlsystem Digital 

63 EWSX EMdronlschesWahlsystemEsdended 

64 f 



Pon^rd Error Correcfion 

Fuzzy Logic 

Frame Relay 

File Server 

File Transfer Protocol 

Feature Test 1 

Feature Test 2 



65 FEC 

66 FL 

67 FR 

68 FS 

69 FTP 

70 FT1 

71 FT2 

72 g 

73 6CP General Indication Primitive 

74 GGSN Gateway GPRS Support Node (361 40) 

75 GMM GPRS Mobility Management 

76 GMM GPRS MobUlty Management 

77 GMM^FGMMApplloiftion Function 

78 GMMJTF GMM Transport Function 

79 GMSC Gateway MobBe Station Controller 

80 GPRS General Packet Radio Senrlce (21,4 kbit/s) 

81 GR GPRSRe^stBT 

82 GSM • Global System for Mobile Communication (9.6 

83 Kbm) 

84 GSM-R Railway (Elsenbahn) 

85 GSN GPRS Support Node 
GPRS Tunneling Protocol 
Global Title Translation 
Graphical Iteer Interfece 



86 GTP 

87 GTT 

88 GUI 

89 h 

90 HEC 

91 HLR 

92 HO 



Header Error Control 
Home Location Register 
Handover 
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1 


HSCSD 


High Speed CIrcuil Switched Date (14,4 


48 


LC 


Load Control 


2 


kbit/s) 




49 


UC 


Line Interface Circuits 


3 


HTML 


Hyper Text Marking Language 


50 


U 


Length of Event Queue Level } 


4 


HTTP 


Hyper Text Tranwer rrorocoi 


51 


LL 


Load Level 


5 


HW 


Hardware 


52 


ac 


Logical Unk Control 


6 


i 




53 


LM 


Lelstungsnnerkmal 


7 


10M 


Internet Call AAanager 


54 


LM 


Load Manager 


S 


ID 


Identifier 


55 


LMT 


Local Maintenance Terminal 


9 


IDS 


Interai^e Debiting System 


56 


LMP 


Load Monftortng Process 


10 


l/F 




57 


LOH 


Iml overtoad handler 


11 


IHUR 


Innovation HLR 


58 


LS 


Load ^te 


12 


lAAEI 


International MODue cciuiprneni luenuiy 


59 


LTG 


Una Tiunk Group 


13 


IMSI 


International MobQe sui>8(mDer laenuiy 


60 


LUP 


Location Update 


14 


!wrr 


Intemauonal Moi>iie TeiecominunicaDDn 


61 


m 




15 


IN 


Intelligent Network 


62 


MAC 


Medium Access Control 


16 


INAP 


intelligent network application pan / 


63 


t^P 


Management Application Part 


17 




MteDigent network application protocol 


64 


MAP 


Mobile Application Pait 


18 


I/O 




65 


MB 


Message Buffer 


19 


lOP 


Input/OiAput Processor 


66 


MOP 


Maln Control Processor 


20 


ICS 




67 


MDD 


Magnetic Disc Device 


21 


IP 


internet Protocol 


68 


MDS1 


M^sage Distributor Stage 1 


22 


IPC 




69 


MQ 


Media Gateway 


23 


I&41 


EIA netwofk protocol standard] 


70 


MM 


Mobility Management 


24 


ISDN 


Integrated service uigttai NeiworK 


71 


MML 


Manager Machine Language 


25 


ISM 




72 


MO 


Mobile Originated 


26 


ISP 


Internet Servtee Provider 


73 


MOC 


MobOe Originated Call 


27 


ISS 




74 


MOD 


Magneto-Optical Gteo device 


28 


ISUP 


ISDN User Part 


75 


MP 


Main Processor 


29 


ISV 




76 


MP:AAL2MPAAU 


30 


rr 




77 


MP:ACC MPforAccountlns 



31 ITU-T International 

32 TelBcomm. 



Tdeoommunlcation Urdon- 



33 lu-LIC 

34 IWF 

35 IWU 

36 J 

37 Java 

38 JDK 

39 JVM 
40 

41 fc 

42 K1207 

43 I 

44 LI 

45 LAI 

46 LAN 

47 LAPD 



lu interface UC 
IntenA^orMng Function 
Interworking Union 



Java Development Kit 
Java Virtual Machine 



Conformance Tester K12S? 
Level 1 

Location Area Identity 

Local Area NeAworfc 

Unk Access Protocol Ibr D-channel 



78 MPrGTT MP Global TItte Translation 

79 MP:LC MP Load Control 

80 MP:LM MP Load Manager 

81 MP:LS MP Load State 

82 MP:MM MP for MoblDty Management 

83 MP:PD/SH MP for Packet DIspafchlns and S^on 

84 Handnng 

85 MP.RANAP MP Radio Access Network AppficaUon 

86 Part 

87 MP:SLT MP Signaling Una Tennlnatlon 

88 MPU Main Processor Unit 

89 MPU-D Main Processing Unit O (CS2.0) £ in CS2.1 

90 MS Mobile Station 

91 MSC mobile iservtees] switching center 

92 MSC Mobile Station ControUer 

93 MSP MP-SP protocol 

94 MT Mobile Terminated 
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1 


MffC 


Mobile Temta^ng CaO 


47 


PIF 


PubOshed Interhice 


2 


MTfP 


Message Transfer Part 


48 


Pll^+ 




3 






49 


pum 


Public Lands Mobiie Network 


4 


MAS 


Non Access Stretom 


50 


PM 


Performance Manaoement 


5 


NNI 


Network Node Interface 


51 


PNNI 


Private NNI 


6 


NOM 


Nomnal Operafion Mode 


52 


PO 


Packet Oriented 


7 


NS 


Network Service 


53 


pps 


packets per second 


g 


NSE 


Network Service Entity 


54 


PRM 


Packet Routing Manager 


9 


NSS 


Network Switching Subsystem 


55 


PS 


Pack^ SwBch . . 


10 


NSVC 


Network Service Virtual Connection 


56 


PSA 




11 


NT 


Network Tennlnafion 


57 


PSTN 


nuoiic owiicrnng i eicwui i m i ui uuuiion NenvorK 


12 


NUC 


Nailed Up Connection 


58 


PT-A 




13 


o 




59 


PTM 


PolntoTo-MuHlnfiint 


14 


OAM 


Onen^on. Adnnlnielfatinn And Maintimanea 

^'I'wmWWIli nwi||lill9UCIUUII miM IViail SUM Rill IWV 




DTD 


roini- 1 ©■r'oini 


15 


OC 


Object Class 


61 


PVC 


Pof ffiafMMif Ulrhlat ^iMivmat 


16 


OEM 




62 


Q 

H 




17 


OLH 


Overload Handle 


63 


QoS 




18 


OMC 


Operation &nd A/teintenance Cantor 


64 


QUICC 


««ua«i iiiusyiaivu wuniniuriKTcUioii woiiu oiler 


19 


OMH 


Overload Message Handler 


65 


f 




20 


OOM 


Overload Operation Mode 


66 


RANAP 


r\auiu Mccess iNeiwortv Mppiicanon "art 


21 


OPC 


orlglnaUng point code 


67 


RHS 


Resoiirca Handle S^uhsv^Ain 


22 


OS 


Operating System 


68 


RLC 


Radio LinV Confml 


23 


OSI 


Open System Intereoivieotion 


69 


RLP 


Radio Link Proi'nnnl 


24 


OSP 




70 


RM 


Rasnurco Msnanpnnont 

• XC^WWIWO IVICII 10^64 HOIK 


25 


OSUN 




71 


r%iiiw 


i\ouio iNeiwonv wwiixroiier 


26 


OTP 


Overload Treatment Process 


72 


RNS 


i^sHuv iMeiwDiK ouDsysiani 


27 


OTCP 




73 


RR 




28 


OTRP 




74 


RRM 


Radio Resource Manactement 


29 


- OVL 




75 


RTM 


RniiKnn Msananor • • • • 


30 


OVLJDPU 


76 


RX 




31 


OVL^MEM 


77 


s 




32 


OVLJOS 


78 


SA 




33 


OVL^Lx 


Overload Level X 


79 


SAG 


Sianannn Aaent 


34 


P 




80 


SC 


SlftfH'ch r^nntmanHftr 
«9«viiwii wwiiuiiaiiud 


35 


PCM 


Pube Code Modulation 


81 


SCB 


CoittrcM Shelf Basic 


36 


PCP 


Pertpheral Contno! Platform 


82 


SCCP 


S^naflng Connection Control Part 


37 


PC51 900 Publfc Ceflular System 


83 


SCE 


Control Shair Pytpnripfl 


38 


PCU 


Packet Control Unit 


84 


SCMG 


SCCP lUIananampnt 
**wwr ivioi lay 91 uciii 


39 


PD 


PaiCket DIspatK^er 


85 


SCP 


Service Conbiol Pofaift 


40 


PDCH 


Packet Data Channel 


86 


SDH 


Svnchronous Dloitai Htanarehv 


41 


PDH 


Pleslochronois Digital Hierarchy 


Oi 


0(90N 


Serving GPRS Support Node (391SCH'36140) 


42 


PDN 


Packet Data Network 


88 


SH 


Session Handling 


43 


POP 


Paok^ Data Protocol 


89 


SIM 


Subsc^ber Identification Module 


44 


PDT 


Packet Data Temdnal 


90 


SIMVT 


Simulation Testframe f. csSi processing 


45 


PDTCH 


Packet Data Traffic Chwnel 


91 




(VermlttiungstechnilO 


46 


PDU 


Packet Data Unit 


92 


SIP 
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1 SLR SGSN Looatlon Register 

2 SLT Signaling UneTeimlnation 

3 SLT Signaling Link Terminal 

4 SM Service A/lanagement 

5 SMP 

6 SMS Short Message Smice 

7 SMSC Short Message Service Center 

8 SN Switching Network 

9 SNDCP Sub Network Dependent Control Protocol 

10 SNMP S&nple Network Management Protocol 

11 SP Server Processor 

12 SPC signaling point code 

13 SPU Service providing unit 

14 SP:BSSOP Server Processor for BSSGP 

15 SP:GTP S«ver Processor for GTP 

16 SP:ISP Server Processor for ISP 

17 SP8 Synchronisation Point 8 (Online) 
IS SR Service Release 

19 SRM Signafing Resource Management 

20 SS Subsystem 

21 SS7 Signafing System No. 7 

22 SSNC Signafing System Networic Control (39190) 

23 SSS Swlb;hlng subsystem 

24 STC SignaTing Transport Converter 

25 STM Synchronous Transfer Mode 

26 SUN Service Unit 

27 SVC Service Call 

2S SVC Switched Virtual Connection 

29 SW Software 

30 SWT Sotlware Tracer 

31 t 

32 TA Timing Advance 

33 TO Transcoder 

34 TCAP Transaction Capabllffles Application Part 

35 TCP Transmission Control Protocol 

36 TDM Time Division Muitipledng 

37 TELCO Teleoommurtcatlon Company 

38 TFC Transmission Flow Corirol 

39 TFI Temporary Flow Identtfler 

40 TLU Temporary Lo^al Link idenWier 

41 TRAU Transcoding and Rate Adaptton Unit 

42 TS Tlmeslot 

43 TS Transport Signaling 

44 TSC TRAU Server Card 

45 TTM TalkToMe 

46 TX Transmit 



47 u 

48 UBI unique buffer Identification 

49 UCR UMTB Switching Subsystem Release 

50 UDP User Datagram Protocol 

51 UE User Equipment 

52 UL UpLlnk 

53 UMLA Unmed Mediation Layer 

54 UMSC UMTSMSC 

55 UMTS Urdversai Mobile TeleoommunlcaHon System 

56 URI Ur^orm Resource indicator 

57 URL Uniform Resource Locator 

58 USF UpDnk State Flag 

59 UTRAN UI\/rrSTerresiriai Radio Access Networtc 

60 V 

61 VC Virtual Connection 

62 VCPU Virtual Central Processing Unit 

63 VCPU-OL VCPU Overtoad Level 

64 VLR Vi^r Location Register 

65 VMSC Visited MobHe Station Corttrbller 

66 w 

67 WAN Wide Area Networtc 

68 WEB 

69 WN Wireline Networks 

70 X 

71 y 

72 YATP Yet Another Tunneling Protocol 

73 Z 
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3 Introduction . 

WilWn the Siemens SURPASS product femUy, the value-added IP services become more and more 
important and show new needs in temis of perfomiance and reliabBHy. This is the reason why the running 
environment of these services has to be realized for carrier-grade scaling and availability. Like in the 
EWSD, solid overload detection and handling mechanisms are the precondition for an optimized use of 
the resources and a higher robustness of the system. 

It has been chosen to develop and implement these services on the so-called Commercial Platform 
(CoPD whidi refles on a SUN NeU« running SUN's Solaris operating system. 

The CoPI runs inside the SURPASS architecture and is thus connected to the "EWSD part" of the 
hiQ9200 The B/VSD subsystem has its own overload detection and handling system (based on the 
STATOfi algorithm and LTG local overioad control). This quite complex proprietary system defines sbc 
levels of overioad, defense mechanisms and lnter-process/processor§ overioad messaging. For th^ 
reason, the present overioad handling mechanisms should take advantage of this already available work 
and stay compatible with it. From a SW point of view, the CoR becomes a platfomi wthin an EWSD 
SURPASS switch. The SW. which comprises the new services. Is spread across all platforms, induding 
CoPl. SW running on the CoPl must invoke any SW interfaces on CP or LTG and >*» ye"^- provWe 
this capability, a physical and a logical connection must be established between CoPl and EW^D-MWV 
interfacing the CP-SW and LTG-SW. 

The system described in this document takes into account the fact that the CoPl deals with 
other kinds of applications than the EWSD does. These applications fomn two groups: a first 
group that defines the Open Service Platform (OSP) and a second group that defines the 
Packet Control Unit (PCU). Ail these applications deal with IP-networks and IP-services on one 
side and with classical telephony on the other side. They need other measurements and 
handling mechanisms than the ones used In the EWSD processes. 

A typical Internet Services server does not provide any support to limit tfie rate of connections 
per second and/or Una rate of requests per second to dynamically adapt to server load and/or 
satisfy a policy constraint on sen/ice guarantees. As a result, it is likely for an Internet Services 
server to become saturated (overloaded) when ^nricing content to dients. In an overloaded 
condition, a typical server suffers severe peifomnance degradation, with the overall throughput 
felling significantly and client connectivity and perceived perfbnmance (such as the delay in 
completing the request) becoming unpredictable. In addition to susceptibility to overload, cun-ent 
servers lack the ability to monitor the incoming load and differentiate between different types of 
sen/ices, espedally in scenarios such as virtual hosting in which multiple sen/ices (e.g., different 
Internet sewlce applications) may be co-located on the same server platform. Wrthout overload 
protection and service differentiation, a typical sender vw>uld only be able to provide "best effort" 
service to its customers. 

Here we develop control mechanisms and poiides such ttiatthe GoPI (i) tracks and avoids non- 
manageable overioad situations before ttiey set in (predictive fuzzy logic rules), C") avoids also 
short higher toad picks (transient fuzsty toglc rules), and (iiO provides sen/ice differentiation 
between different applications based on spedfied policies (a(^lication specific fuzzy logic njies). 
With such a support a server becomes self-suffident In preventing overioad and can 
dynamically configure the control mechanisms provided to obtain tiie desired perfonmance 
effects One of the advantages of tinis approadi is tiiat no additional or new equipment needs to 
be deployed separately to provide similar capabilities. Furtiier, this pemnits existing server 
installations to be upgraded in an application and network transparent manner, i.e., witiiout 
deeply modifying applications or existing network connectivity. Anotiier significant advantage is 
ths* the control settings provided can be used to trade an overioad situation as it unfolds, 
generating notifications or control actions as necessary. This greatiy simplifies administration 
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and capacity planning for a server, and by extension for a server farm, thereby reducing system 
management costs and complexity. 

The provided fuzzy logic programming language authorizes all levels needed for a fine tuning of 
the overload handling. There Is no limit for the granularity of the overioad decision and overload 
treatment models. 

Furthermore, the idea to use the results of the rules calculation in combination with the output 
variables calculation allows a simple description of overioad actions to be ^pedally taken. 
Because a rule describes a predse mix of overioad conditions like common resources overflow, 
application spedfic queues overflow, this same aile can be taken as decision base for overioad 
handling actions. Every new recognized overioad situation can be Introduced in the fiizzy logic 
expert system database and actions can be taken according to it 

The proposed fuzzy logic toolbox allows giving different priorities to the rules used for the 
overioad status calculation. This pemnits different levels of precision In tiie overioad calculation. 
IVlore important rules get a higher priority factor. 

3.1 Scope 

The scope of this document is the specification of the requirements for a solid load monitoring of global 
resources on the CoPl and local perfonmance of given applications running on It Then an overioad level 
calculation has to be defined. This document will also propose mechanisms for overioad handiingi 
matching the different applications concerned by the overioad. 

Solid load monitoring of resources and mechanisms for overioad handling are a precondition to increase 
the robustness and the perfomiances of the system. The tenm resources as used In this document 
subsumes any kind of system resources, I.e. CPU time, memory, processes, buffers, semaphores. 

As long as the underiying OS supports the control of some of these resources, a simple resource 
management can be based on those UNIX features. However, for a more sophisticated managed 
allocation and use of resources must be controllable by the UMLA. This involves creating a closure on 
system calls fike malloc, forte, Mil, and other resource expending or releasing OS calls. Resource 
management realized this way will be the base for treatment of software enrors, Implementation of fail- 
over strategies, resource trace tools, and overioad control. 

Resource Management must be completely hidden fironri the appGcation. There Is no API for it. However, 
resource management influences the development of application indirectly reflected in the conesponding 
user guidelines. Even applications not designed for the UMLA (commercial products) are controlled by it, 
thus protecting the system from those applications. Note that this does not mean that commercial 
products cannot be disastrous for the system, but ft reduces the risks. 

Overioad handling is needed in order to provide: 

• a stable system t)ehavior, 

• guaranteed throughput / performance, 

wfthin overioad conditions. 

Throughout the system overload handling mechanisms are divided Into overioad detection and overioad 
treatment which are implemented on various units / platforms according to the same basic principles 
defined In [8IEM01]. 

The quantitative definition of the requirements at>ove, I.e. guaranteed throughput and overioad level, has 
to follow some predefined values according to some preconditions: 

The specifications conceming PSTN-switching might be used DTUTQ5431. They require that the effective 
load should not fall below 90% of Load B even if the offered incoming load increases to 150% or 200% of 
Load B. Load B is defined here as a load level 20% above the planable load (Load A). Under Load B, the 
system has to provide fiill service, however under limited requirements conceming processing delay. 

For telecommunication switching systems, overioad Is defined among the following load levels: 
Load A; nonmal load conditions witii respect to network dimensioning. 
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Load B: high load level, no overload measures have to be taken under these conditions. 
Qverioad: traffic is above maximum node perfonnance« traffic r^ectlon should be perfomted. 

3.2 Overload Handling 
3.2.1 Terminology 

The commercial platfomi (CoPI) encompasses the Open Sen/ice Platfonn (OSP), the Packet Control Unit 
(PCU) and Extemal Server Unit (ESU). Open Service Piatfomi and Pack^ Control Unit are 
Interconnected to the EWSD Core Switching System via non-open interfaces. The EWSD Core S>witchlng 
System may either be the B/VSD das^c line or EWSD innovation line. 

The Extemal Sen/er Unit hosts standalone applications that do not necessarily need to communicate with 
EWSD (e.g. the RADIUS service). ESU and EWSD Core Switch are not directly Interconnected. The 
Packet Control Unit runs those parts of the call control for packet networks which Is required in addition to 
the re-used EWSD call control (e.g. H.323 protocol family, MGCP protocol). 

The Open Sen^ice Platform runs converged sen^ices. I.e. sen^ices combining features of the PSTN/ISDN 
vyrith features realized using IP technology. 



Programnning Guidelines 



-standardUNIX 
» standard libraries 
•socket API 



• Platform functions 
supporting 

•high availability 
•aiarmingi/f 
•SW- maintenance 
•timer management 




Integratio 
of Commercial 
IT Sofhware 
(e.g.DBl Corb# 

System 
Independence 



Figure 18: The Unified Mediation Layer (UMLA) 

The commercial platfomrt is made up of the commercial hardware, the commercial operating system, the 
commerci^ cluster software and of additional platform functions and programming guidelines, called 
Untfied Mediation Layer (UMIJ^). UMLA is not an OEM product but is provided by iCN WN CS. 

The programming guidelines of UMLA describe how applications must make use of the commerdal 
piatfonn functions, so that a nonnnterfering operation is made possible and portability to other OS and 
HW is not precluded. UMLA will not exclude the integration of commercial software. 

In addition to the programming guidelines UMLA provides APIs and functions for alamning, for 
communication with the EWSD core and a set of basic functions like timer management, tracing, SW 
en-or reporting, IPC management and intranode context saving. Later on, when requirements with respect 
to sen/ice availability increase, UMLA may offer additional functions for Inter-node context ^rvlng and 
Inter-node communication, etc. 

3.2J2 Principles of Overload Handling 

As a central point, the overload handHng is divided into overload detection and overload treatmenL 

• Overload detection: This part defines the methods of measurement of load situation and 
the categorization of overload levels. 

• Overload treatment This part defines the measures, which are started after detection of a 
certain level of overload in order to return to normal operation, 

3 -2.2. 1 Overload Detection 

For the overload detection at one piatfonn the following general pilndples should be used: 
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. A simple quantitative criterion shall be defined which indicates the load situation of the 
platfbnn. 

• For this criterion, one or more values shaO be defined for the definition of overioad states. 

. In nonnal state, the platfbmi shall wortc in the same manner, as without any implementation 
of this LWI. the additional load for overioad detection should be less than 2%. 

. A hysteresis shall be included between switching on/off for all overioad tevf>f Pi^rrt 
frequently overioad switch on/off. which causes additional mes^ges and therefore 
peifonnance loss. 

• overioad detection mebhanism has already been Introduced on CP. LTG, and MP. 
■17 2 2 O verload T*^^t?rH?P"* 

Forttie overioad treabnentv^thin one platfomi thefollovwlng general principles should be used: 

. For each overioad level a specific overioad treatment should be defined which reduces the 

woric which has to be done by the critical component (processor, memory, queue length...) 

and therefore the probabUlty of an ongoing increase of system load signincantly. 

• Sen/ices already provided by the core networic and negotiated vinth the CoPI should not be 
discarded if the system is in overioad. 

• Requests for new sen/ices can be rejected depending on the overioad level. 

. Overioad treatment measures will be provided, which will be included later on in an overall 
overioad concept. 

3.3 System Functions from User Vievirpoint ^ ^ , . » 
Overioad handling must be completely hidden from the "ser. Overioad Control has ttie task tode^ermme 
load slates, deliver this InfomiaBon to applications, and pertiaps distnbute the load onto the different 
processors. 

s> H must t)e transparent for the user. 

3.4 Assumptions and Dependencies 

These aredie same as fiv die referenced BOs [22]. 

- 3.5 Effects on Other Systems and Procedures *■ " " 7. * . 

The Overioad Handling System of the CoPI has to fit into and possibly communicate vinth the Overioad 
System of the EWSD and/or the components of ttte SURPASS product family. 

3.6 Differences from Requirements 

Due to the high adaptation potential of the described concept, application specific resources will be 
monitored and used for the second part of the Ijoad Monitoring Process. 

3.7 Development Steps 

*** Replace this line by the text body of the dnapter **• 

3.8 Documentation Overview 

*** Replace this line by the text body of the chapt^ *** 

3.9 Outstanding issues 

*** Replace this line by the t«(t body of fte ctrapter 

4 Realization 

IMPORTANT NOTE 

In the foUowing description, all functional blocks of the toad oontrcd concept can be ^er understood as 
separate processes or as procedures of a unique load control application ^Isfor perfomnance reasons). 
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4.1 Overload Detection 

Overload detecBon encompasses a set of phases like local and remote resources load monttoring, 
calculaQon of an overall overioad level, system status switching and start of the overload treatment. 

Behind these functions, the overload detection system has to report Its current status to the concerned 
entities (NetM, CP. and LTG). (Please see Communicating Overioad Level to Other Platforms, page 18.) 

4.1.1 Local CoPI Overload Defection 

Ilie CoPlfii^ logic overload (^culatioii leads to contiimons valaes between 0 and 1. If needed fi>r conipatitnli^ 
with the {nevions load control S W, it is possible to le-scale to a discrete range from 0 to 6. 

Inconttastto the concept of CP overload control no ejqilidt load states need to be defined for the CoPl, Le. the CoiPl 
is consideed not to be under ovedoad if the "over-" load level is between 0 and a given tbreshold. Fuifhennoie, the 
fiizzy logic delivers a continnous overload lewd, Oat is nnxch more predse than a classical if then else / switch 
aichitectore can produce. 
4. 1 . 1 . 1 Load Monitoring Process 

The CoPl's opiating system (UNIX, SUN Solaris) consists in applications and processes that are called by the 
kernel (endless loop) depending on their pnoiily. in this environm^ the LMP (Load Monitoiing Proce^) should 
run as a single process (mono-thread). It should be quids and tune intmnpt driven. It should get a higher priority but 
not use more than a predefined amount of memory and CHJ time when called (budg^ defined in Si equivalait to a 
sustained load of 2% of die CPU resource dnxiiig its run). 
The LMP 1^ to monitor difibrent kinds of resources: 
GPU usage 

- Memoryusage 
I/O usage 

- External System Overioad (CPjOVL.. .) 
Applications spedfic resources 

The LMP must have two running modes: 

- a basic one m non-overloaded operation in order to detect an overioad sitoadon by cheddng a restricted amount 
of main resources Hke C3?U, memory and ios, 

- an overload mode running under overioad situation, which makes a more detailed anatyas of the overload 
situation and fliat checks an higjier amount of resources (not onty CPU, memory and ios, but also midication 
specific ones). 

Under normal situation, die LMP just checks the operating status of the CoPl and, in case of detection of a possible 
overload situation, switches to its overloaded mode. 

In overloaded mode, die LMP chedcs extra resources m order to possibly detect flie overload responsible 
applicatioit 
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I Normal Operation Mode] 



I Non-overioad M- 
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Get 
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Get: 



Compute COPL_OVL using 
pted^hwdOVLrBL-Madd 




Figure 19: Operation modes of the LMP (NOM/OOM) 

The left Dart Of the Overtoad OperaHon Mode (COM) Is very similar to the Noimal Operation Mode 
mOMV th^Si dSoete the^oontrd loop ftequency. If the chosen programming technique aUowr it. 
the two processes could be merged Into one (with two threads). 

The NOM must be a Oght process, checking a restricted fix amourrt of maJ" jesourc^. is not ron^lat^ 
to ttie running applications on the CoPI. It says if the CoR (globally) should enter the OOM. This part of 
Se lis fe fte Sn?for all versions of the CoPI. like for example the PCU or the OSP. t can rely on an 
F^Sy Sc iSne^^^^^^^^ In C or Assembler (for higher speed), a prc»to^ ?,f ^'^^J^S 
me SRfT. IteoonflSuration can be adapted through its FL-Model conRguraton file (like a ^npt or 
d^^ . Si oLr aspect is that the NOI^ consen/es some values between its mns and "s^^^in? 
eliminate some Wnds 6f problems like short-time overloads that do not require an ^erload treatment 
Typically the NOWl calculates the "climbing factor" or increase/decrease coeffiaent (df/dt). 
The OOM is should stay a "nghf process (not more than 50% more resource consurnption than the 
dfeSdS^^^^ amtSnt <5 resources (the sames as NOM and addWonal app«c^on spcciflc 
nScS If planned) It relies on a Ft driven expert system that can compute which '"easures have to be 
taken in order to drive the CoPI back to the NOM. Its conllguraflon can be adapted through its f^-Model 
SSurSSn iJe me a script or database). A kind of overtoad responsibility check Is p^fonried 1^ the 
S ^Sorting to the results, some overtoad notification signals are sent ^d overtoad irandling acho^ 
Se tekw^SS/erae coi^onents of the CoPI. It decides how the Overi^d Treatment has to vrortc 
The OOM FL-Model depends on fte applicaHons/modules running on ttie CoPL 



4.1.1.2 Mo TiTtnred resources 

^gtob^mSad can be checked using standard OS functions or UMLA API. The returned value is a 
pSIrtage of the whole CPU capacity On a further step, it could be a per^PU 'Measurement in c^e of 
muSjSe CPUs). Before using this raw measurement, it can be useful to go through an intemiediate state. 
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making the CPU raw measurement conrespond to a CPU overtoad level (OVLjQPU). TNs tntemi«fiate 
statement is mostly useful if the NOM does not rely on Fuzzy L^ic, Indeed the FL pnforms automaUcaily 
such conversions. 
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Figure 20 CoPI: CPU load level and its fuzzy equivalent level 
(only provided as example, values to be discussed) 

MEMORY (NOM/OOM) 

The global MEMORY load can be checked using standard OS functions or UIMLA API. The r^med 
value Is a percentage of the whole MEMORY capacity (In a furUier step. It could be a per-CPU 
measurement in case of multiple CPU or...). Before using this raw measuremerrt, it can be us^ul to go 
through an intemnedlate state, making the MEMORY raw measurement correspond to a MEMORY 
overtoad level (OVL_ MEM). This intemnediate statement is mostly useful If the NOM does not rely on 
Fuzzy Logic, indeed the FL performs automatically such conversions. 

MEMORY ■__ 

lUsage OVL mem 

0% 0% 

10% 3% 

20% 5% 

30% 10% 

40% 25% 

50% 50% 

60% 75% 

70% 90% 

80% 95% 

90% 100% 

100% 100% 



ui 

5 



100% 
90% 
80% 
70% 
60% 
60% 
40% 
30% 
20% 
10% 
0% 
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Figura 21 CoPI: Memory charge level and its fuzzy equivalent level 
(only provided as example, values to be discussed) 

I/O OVOM/OOM) 

The global I/O load can be checked using standard OS functions or UMLA API. The returned value is a 
percentage of the whole I/O capacity. Before using this raw measurement, it can be useful to go through 
an intennediate state, maidng the I/O raw measurement correspond to a I/O overload level (OVL lOS). 
This intemnediate statement is mostly useful if the NOM does not rdy on Fuzzy Logic, Indeed the FL 
performs automatically such conversions. 
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Figure 22 CoPI: l/Os usage level and its fuzzy equivalent level 
(only provided as example, values to be discussed) 



OVERALL SYSTEM OVERLOAD (NOM/OOWO 

Being interconnected to other SURPASS components that Interact \Mth It the CoPl has to get mfomiation 
about the whole system health and communicate its own status to the rest of the system, if It enters an 
overload status. This depends on the scenario (OSP or PCU) and also the use of load-balancing 



For the UAP, it is Important to stay infonrted about the overload situation of Its connected neighbors 
inside the considered SURPASS configuration. Overload Status Messages are supposed to be sent from 
the overloaded components to the CoPI (belonging in the rame way to the overall overioad control 
system). 

A Wnd of priority has to be defined within the LMP in order to react as a slave inside the overall overload 
handling of SURPASS. If ttie central can control enters the overlc^d ^atus 6, then it sends a message to 
the possibly responsible units In order to tell them to reduce the admission of new calls Inside the system. 
This should also \work specially In the case where the CoPl hosts the PCU. The PCU can be at *e origin 
of new call attempts. The PCU has to react on some congestion signals coming from the central call 
control system (B/VSD CP). The CoPl Is notified via overload messages firom the CP. 

APPLICATIONS SPECIFIC RESOURCES (OOM only) 

Once the OOM Is reached, it is compulsory to detect which part(s) of the whole system is (are) 
responsible for the overload situation. To reach this, one needs some applications specific 
resources monitoring. Most of the applications use the same kind of resources. We regroup 
these ones into five main types (similar to the ones In the LTG load control and related to ttie 
application configuration file within the UMLA): 



These resources can be controlled either by the UMLA and/or the OS. The LMP will then 
access the resources through one of them. The LMP may consider the overall consumption of 
these resources and determine the percentile use for each application. These common 
resources are essential for the well functioning of the CoPI and the extent of their pools is 
designed to be sufficient. But their availability under heavy load must be monitored. This 
supervision is not meant to be a means for nicely tuned load regulation measures but it Is an 
"emergency break". If needed, they will be used for the detemnlnatlon of the application(s) 
responsible for the overioad situation. 
Tran^ent Parameters ^OM/OOM) 



mechanisms. 




timer blocks. 



heap blocks (UMLA : queues^ 
memory blod^s (UMLA : pools)» 
- tran^ction control blodks. 
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These parameters are useful In order to avoid a too rapid reacfion against local overtoad ^tuations that 
are not significant and therefore must not start overload treatment procedures. It is still under analysis 
which fonn these parameters will take. 

The simplest form is the tradng of the time interval since possible overload status entry. The next step is 
to tune this interval so that the system stays stable and reacts only on higher overload duratioa 

4.1,1.3 Tb ft>JnTfna1 O peration Mode flSFOM) 

The NOM is in charge of controlling the (over-) load level during normal operation. According to the new 
calculated level, it eventually switches to the Overload Operation Mode (OOM). In order to make this level 
calculation, the NOM needs the in 1.1.1.2 described inputs (only the system relative ones). Using the 
fuzzy logic descriptive model, it is easy to mix these inputs together and get the overioad lev^ using a set 
of basic rules. 



41.13.1 Overview of fwzy logic used in NOM 

In NOM, every CHKJTIME sec, the pred^ned resources are checked (thnDugh CoPI OS/UMLA) and are 
stored for following treatment. The next step consists In fuzzilying these crisp values Into fuzz^ variables. 
The sequence of fu2zy logic Onference) processing can be broadly divided Into two functions: inference 
and defuzzificaHon. The inference process isegins with the processing of the production rules. Individual 
mies consist of a condition block (also called the antecedent or "IP block) and a conclu^on block (known 
as flie consequent or "THEN* block). The inference process proceeds from the conditions to the 
conclusion, and then to the logical sum. To get a usable output, however, a deffuzifier operation must be 
performed to convert tiie fuzzy values back to a fixed, discrete output value, here the overioad level for 
instance. 



Normal Operation Mode 




Figure 23: Fuzzy Logic applied to NOM 



CPUJJQADJ/BRYJitGH Alffi MSWOf? Y.LO/UD. VERY JilGH 
MB tOSJX}ADJi/BHy_HieH 
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1 THEM OVERLOAD_La/ElwVE>^-W^" 

I wrm HHSHESTPfjOBABiiny 

figure 24: a typical (and very true) rule example 



AH traditional logic operatore (and. or, not..) are available and also new ones that work only for fu;^ 
Sgl?SSn^sSc?^te^ S iisi^ th'an ded'udng complicated mathematical fomiulas Java to t« ^ 
«n«it,oo«ld wWi the Introduction of new variables n the system. The rules can be deduced from 
£^%en^a?d SSons. uS^ a quite stralghtfSU.nl Intultlva deduction. For example, 
experience (thumb rules) in system tuning can be directly reused. 

Afirst pnDposal for the NOWl fuzzy model is done here according to the requirements emltt^by IC^ WN 
CCSe S These requirements Impose to the NOM to stay platform specific and not aPP';^?J^^ 
Th^ m4ns that only a part of the monitored resources >ArtlI not be taken Into account In the NOItf ft^ 
JSi^^ieremalhlng^^ are to be used in the OOM anyway. The fuzzy kernel uses a fuzzy 
modd deBnIHon file "overloadjdetectlon_model.fuz". 




Figure 25: NOM fuzzy inference engine 



4.1.13^ FnzKification stage 

A crtsp input is a parameter coming from the 
monttoring system (CPU, memory, los, CP-OVL), It is a 
number comprised In a predefined interval, for 
example for the CPU usage input parameter, the CPU 
crisp input is defined as a real number tjetween 0 and 
1 (or 0% and 100%). For this crisp input, a fuzzy 
variable has to be defined using "sets" of the fuzzy 
language: 

We define here eleven intensity levels of CPU usage 
(0...10), ranking from 0 to 1 for the crisp input 
parameter. For example, the definition of level 3 of 
CPU usage is defined through a trapeze starting by 
20% climbing to the maodmum of validity from 27.5%, 
staying at maximum fill 32.5% and decreasing to zero 
by 40%. 




Rgure 25: fuzzy vaii^le CPU (sets) 
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E.g. for an Input CPU u$age value of 26%, we say that ttie CPU usage fuzzy set 3 (level 3) is true v\ath 
65% validity, it is also the case for level 2, that means that, when CPU usage Is equal to 25%, CPU is at 
the same time in level 2 and level 3 with 65% validity for each. The graphical representation of the CPU 
fuzzy variable corresponds to a part of the fuzzy model file: 
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FlguiB 26: deHnition of the CPU fuzzy variable using fuzzy sets 

Extracting the validity of each fiizzy set for eadn variable according to its crisp value Is called 
"Fuzzification" of the input crisps. 












\'X — ^ — t 

\i i 

1' ! 











...JL.J — 

V\.^ 




L.|C 4, 4 


i.i — , 

mo 




\, 4 




J — 


!•• -j 








\ 


r 1 1 




tA 
CMV 


out 0« t 
:0J 



1CPU {0.1A3,4,5.e.7,8A1O> IN 
2DCPU {P.1.2.3.4A6i7,8^,iq} IN 
3 MEM «>.1A*4Ae,7.WC5 W 
4OMert{P.142A4.5A7.ai9.10} IN 
5IOS {MA3AW.8,9.1C!) IN 

eoios Ri;iL3.4.WA9.iaMN 

IN 

8CPOV IN 



Figure 27: NOM fuzzy variables 
Once all input crisps have been fuzzified. the inference process is entered. 
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The inference proce^ reads the fuzzy rule base and evaluates its oorrtained mles ax»r5Jlng to *e ft^ 
sets coming from the fuzzlficaHon stage. These rui^Jook qurte similar Jo standart ^|?J^;L^ke we 
described ttiem in Rguie 8. the fuzzy niles are buHd foHowing the vveli-lOTOwn IF THEN constnicHoa 
Where the difference between standard (Boolean) logic and fuzzy oS'^^tek^^P^'je. * 'I.'" 
taken by the operands and the mathematical definition of the operators. Where true (1) W 
are the only possible values for operands In standard logic, the fuzzy logic attows operands to take 
continuous or discrete values between 0 and 1 (in Its nomialized form). Some logical operators are 
defined in the standard logic and also in the fuz^ logic: 



NOT 
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—1 




AND 
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XOR 






e 



A characteristic of the fuzzy logic operators Is the possibility to optimize ttieir mathematical definition 
according to ttie context 

A AND B = WHN(AB) but also A AND B « A!jGP(A,B) (algdMalc producO 
AORB =MAX(AB) butalsoAORB = ALGS(A.^ (algebrafic sum) 
NOT A =1-A 

According to these definitions, it is understandable how fuzzy logic allows logic with values b8*ween 0 
and 1 (and not only 0 or 1). Agafin the very true rule {Rgure 8): 

Lets say that rf CPU_L0ADJVERYJ<IGH « 0.7 (after ftizzfffcatlon), MEMORYJX)AD_yERYJHIGH 
lOS^LOADJOERY^HlGH = 0.9. 

then the assessment 

IF CPU LOAD VERY_HIGH MR MEMORYJ.OADJ/ERYJiH3H Am IOSJ.OADJ\/ERYJ1!GH IHirj 
OVBRLOADiLEViijtmRYJitGHWDiHIGHESTPROBABlUT^ 

becomes, if we take M\H as AND operator definition, 

OVERLOAD_UEVEL.VERY_HlGH is tme with 50% (=mln(0.7,min(0.5,0.9)) x 1 .0) 



OVRUnrATRUUBP 



0^. 
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Figure 28: ou^ut of all the rules within the fuzzy model 
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\Nhen all niles have been calculated, the 
resulting sets of Vne output variable have to be 
"accumulatecT. This is done by composing all 
the sets together using an "accumulation'' 
operator, like the logical sum (max operator). 




tA 1 
OSfOVRU) 



DJI 



The result of this operation can be seen in the 
lo>A^r part of the Figure 13. One can see that the 
different rules (here only given as example In 
Figure 12) that generate the output result. 




ure 29: aocumulaHon of the output variable, 
building the ou^ut result variable 



4.1.1.3.4 Defiizzification 

The last step perfonmed by the fUzzy logic kernel within the NOM Is the defTuzificatioa As we have seen 
in the previous step, the fuzzy logic delivers an output result in fomr) of a graph (Figure 13). This result is 
not usable in this fbrni, it needs to converted Into a crisp value to be exploitable in the rest of the NOM. 

Again, It is possitrie to use diverse methods or operators to get a crisp value out of the resulting curve. 
Possible operators are the COG (center of gravity), the MAXMAX (maximum of maximums). Here we 
propose to use the COG. This operator pemriits taking into account all the results of all the rules, where 
the MAXMAX is a pessimistic operator. The COG operator search the center of gravity of the surfece 
between zero (y axe) and the resulting curve from the inference step. In our example, the COG is 0.4 (l.e. 
an overioad value of 40% from mawmum overtoad leveO. With MAXMAX we would have got 0.65 (this 
does not take into account the result of some rules, giving also a result around 0.2 and 0.4). 

In a first step, the COG defuzzification method will be taken. If teste show that the mottel reacts too 
optimisfically to overioad situations, then further tnvesHgations have to be done in order to determine the 
best-suited operator for the deffuzification. 

4.1.1.3.5 CoPI Overload level <• - 
The value delivered by the fuzzy logic model of the NOM ranks from 0 to 1; so that If-we wanf'fe stay 
compatible with the CP/LTG-Ov^oad levels, we must re-scale from [0:1] to [0;1;2;3;4:5;6]. 



4A.1A The Ov^load Operation Mode fOQlvn 

If the NOM detecte an overioad level superior to a given threshold. It switches to the Overioad Operafion 
Mode (OOM) in order to detemnine the reactions needed to return to a non overioaded situation. Within 
the OOM, measurements are made (resource checking) and connblned to detennine which process or 
application has to slow down, to be alanned or to be aware of tiie overioad situation. Instead of giving out 
a global overtoad level for ttie CoPI as the NOM does, ttie OOM calculates several overload levels 
according to the desired precision of overioad handling reactions. 

That means that it is possible to group processes and applications togetiier and csJculate an overioad 
level for tills precise group. It is also possible to calculate for each relevant process or application. And 
finally it also is possible to calculate only one overioad level for all processes and applications together. In 
fact It depends on flie case OSP, PCU or an otiier server configuration for the CoPI. A detailed analysis is 
provided for the OSP [4.3] and for the PCU [4.4]. Accordingly to ttiese analysis proposals, configuration 
scripte are proposed. 
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Overload Operation Mode 
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Figure 30: Fuzzy Logic applied to OOM 

4.1.1.4.1 Overview of ftezylo^c used in OOM ^ ^ ^ ^ 

The fuzzy logic kernel is the same for the OOM as for flie NOM. Differences can be found by the Input 
variables, ttie output variatries and the special use of the output of the Inference stage of the kernel. 

Once the OOM state has been entered, a check is perfomied every OVL^CHKJTIME, This time interval 
>Mn be set in a first step to the same value as the CHKjnME (NOM) according to the previous experience 
made by the overtoad mechanisms for CP / LTG / MP. 

The same fuzzy core functions and Interfaces are used. The fuzzy kernel takes a fuz^ model definition 
file "overtoad Jreatmentjnodel.fuz": 

-the input variables encompass the ones of the NOM and some 
application specific resources, 

-the output variables define again the overioad level for the v\rtiole CoPI 
but also application specific overioad levds (degree of action to be • 
taken for ttiis particular applic^on), 

-the CoPI overioad la/el is calculated again at that step. 

The aim of the fuzzy l(^ic In the OOM is to determine a level of overioad or responsibility for overioad per 
application/process and also the CoPI overioad level again. The applicaHon/process overioad levels will 
be furtiier used by ttie Overioad Treatment Process (OTP). 



We can see in the following figure the fuzzy Inference engine used for the OOM: 
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Figure 31: OOM fuzzy Inference engine 

After the Inference Process step, it Is possible to 
extract rules validity as sho\fvn in 

Figure 16. 

These values (or a part of them) v^nll be 
transnr^itted to the OTP for further treatment It is 
not the usual step that is used for a fuzzy logic 
expert system. But during the study it appeared 
to be a good solution to help the OTP program to 
take some decisions. This rules validity is kept in 
order to be mixed with the results coming from 
the deFuzsdfication step. 
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Figure 32: output of all the rules within the fuzzy 
modd 

Since it is possible to associate a rule to a set of known overtoad conditions (with known overtoad 
handling acUons), getting the validity values of the ndes permits a precise overtoad handling decision, i.e. 
in the way an expert system acts. 

4.1.1.4^ CoPI Overload level 
Same as 1.1.1.3.5 ... 

Open issue: shall we use the results of the appfic^on specific overtoad calculation by calcidaUng the 
CoPI overload level at that step or shall we re-use the NOM fuzzy model to control again the lesouroea 
Further InvesHgaBons must be made. 

Arguments: 

- one model with two separate rule-sets : only one script download and one instance of the fuzzy 
calculator, 

- two models with each one rule-set : simpler administration but more resource consumption. 
4,1.1.43 AppUcation/process specific oveiiosd level 

Each appIication/pnDcess tiiat runs on the CoPi needs thr^ blodcs to be integrated into the Overtoad 
Management System: 

- dedicated routines to check its spedfic resources status, 

- an associated fuzzy logic variable (definition of sets), 
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• a sel of mies leading from these resources to a spedfic overioad level. 
Depending on the chosen programming technique, these blocks can be integrated either offline or online 
(database). This Issue Is open and is not In the scope of tWs document 
Another ciassfficatlon could be also done fbrthe global role of the CoPt PCU, OSP. and ESUN... 
ConfiguraBon files can be done for each of these soluQon padcages. 

4.2 Overtoad Treatment ^ w 

After the Overtoad DelecOon. Overtoad Treatment has to be started In order to come bfck to a non- 
overioadcd sftuatlon. The Overioad DetecHon and Its assodaled oomponente deliver a CoPI Overtoad 
Level. appDcatlon/process spedflc Overioad Levels and overioad rules validity values to the Overtoad 
Treatment (OT) program. 

Accoitllng to these Inputs, the OT has to decide actions to be taken In order to bring the system back to 
Its nomial status. To do this, the OT has to start actions locally (wKhln the CoPO and/or remotely by 
sending overioad messages to the connected equipment. 

AD acUons taken locally belong to the Local CoPI Overtoad Treatment (1.2.1). The other actions ctepend 
on the communication of the CoPI Overioad Level to the other piatfonns (Please see Communicating 
Overtoad Level to Other Platforms). 



4-2.1 Ix>cal CoPI Overload Treatment ^ ^. „ ^^o, 

The Local CoPI Overtoad Treatment Is In charge of taking actions to reduce overtoad locally on the CoPI 
ttsetf and communicating Its overtoad status to other connected piatfonns to first avoW new Incoming 
traffic and second Infomi the system. 

4 2 1.1 Overload Treatment Process (OTP) 

The Overtoad Treatment Process and Its subsystems drive all these features. Four t]^es of mechanisms 
participate to the OTP: 

5. Decision of the acOons to be taken, 
6. Active or direct loMlgyedpad. reduction. . . .. . _ 

7. Passive or Indiract local overioad reduction, 

8. Passive or Indirect remote overioad reducHon. 



Mechanism 1 and 2 take place In the Overioad Treatment ReducHon Process. Medianisms 3 and 4 take 
place in the Overioad Treatment Communication Process (extemal and Internal stages). 
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Figure 33: Uie Overioad Treatment Process In the CoPI 



4.2.1.1.1 Overload Treatment Reduction Process (OTRF) 

4.2> 1,1.1.1 Overload treatmeat ideatification 

This process first decides whlcii actions (and action fypes) have to be tal<en according to the diverse 
overload levels and rules validity it becomes from the Load Monitoring Process (IMP). WiOi actions we 
•mean here active or passive, local or remote, increasing or decreasing. 

- Active action: action that acts directly through the OS or the UMLA on 
applications, 

- Passive action: acBon that acts Indirectly through a common interface 
(thresholds in a self-controlled -standalone- application), sending 
overload levels to the appltcations/processes» 

- Local action: action acts local on the CoPI. 

- Remote action: action sends messages through Interfaces to ^eternal 
platforms/processes, 

- Increasing action: action increases load rejection, 

- Decreasing action: adion restricts decreases load rejection. 



Then the OTRP starts the needed overload treatment mechanisms. The OTRP treats itself the local 
active actions and delegates all the other actions to the Overload Treatment Communication Process 
(OTCP). 

The reason of this separation between OTRP and OTCP is that local arfive actions distinguish 
tiiemselves from other ones by ttieir mechanisms; they do not communicate with the concerned 
application/process but act dlrecUy on it through the OS or the UMLA (for e)(ample by reducing the 
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allowed amount of CPU time or memory or blocking their communlcaUon with the nehwoik communlcaUon 
stacks). 

In ODDOsitlon to the OTRP, the OTCP communicates either locally with CoPI hosted 
appllcaBons/processes using messages and/or threshold variables or remotely with other platfomns and 
appitcaflons using the messaging system. 

A l l .1.1^ Memal Stra te gies of Loar t -Rgecticm andRgdactiop . ^ ^ -rK,^ 

The fiizzy logic expert system of the OTP enables classes of senaces/processes to be defined. This 
means that different priorities can be given to the applications/processes running for the CoPI. 

Sem^Sategfes start with toad iBjecOon acfions. This Is done by disabling the upcoming seivlce 
rSqu^s^S^SS^^ Identified In the next parts of this document (application by appflcaHon). as 
In chapters 4.3 and 4.4. 

If the load rejection acUon takes place In the CoPI without alerting the appHcation with messages, it 
belongs to the OTRP, If messages are sent, ft belongs to the OTCP. 

Load relecBon Is the main strategy for overtoad handling. Once the system has reached the criU^l level 
of load, new upcoming requests should be rejected In order to assure the system to recover from the 
overtoad situation. 

Most applications have an Integrated call admission control that accepts or injects incoming requests 
regarding internal thresholds of overtoad. These thresholds are usually fixed , before the start of the 
aopHcatlon. In the present solution, the OTP decides a proportional overtoad level. This should replace 
any predefined fixed tiireshold. It pllows to stay efBdent even if the hardware configuration changes. 
These overtoad levels must be communirated to the appHcaUons by the OTP. using etther tiie OTRP or 
the OTCP. This vray of woridng Is similar to the one of the Load Control within the CP/LTG soflware. 

Please see chapters 4.2.1.1.1. 4.2.1.1.2, 4.3 and 4.4, 

MmtemTls load reduction not planned. If needed in new versions of the load control system, the 
current proposal can be used in extension to the Load Rejection strategies. 

Internal strategies of load i^uction are in that case strategies of attribution (or distribution) of resources 
to applications/processes according to their overtoad status and their pre-defined priorities. 
CPU MEMORY and lOS are shared by these applications/processes. It "is possible to change the 
repartition or attributed amounts of these resources for each application through either the OS or the 
UMLA. If the action takes place without alerting the appBcaflon with messages, it belongs to the OTRP; if . 
messages are sent, ft belongs to the OTCP. 

If a given application/process has reached a critical overtoad level and other appOcations have been given 

amounts of resourx»s they do not use at Uiat precise time, then a good strategy Is to give these resources 

to tile overioaded application/process so that ft can accomplish its task and return to a normal load 

sttuation. As soon as this Is done, the re-routed resources can be given back to their owners. 

That means that In overtoad status, a dynamic resource sharing could be achieved, and that the 

repartition would be done by the fiizzy logic expeA system. 

4^.1.1^ Overtoad lV«atm«itCoimniiiucalion Process (OTCa^ 

This process is In charge of relaying the overtoad treatment actions (decided in the OTRP) to local or 
remote applications/processes/equlpment using system messages. These messages can be sent using 
the UMLA and/or crther communication protocols, depending on the destination. 

The applications/processes addressed by the OTCP can be of two types, local or remote. Local means 
here that they run directly on the CoPI ftself and remote means that they run on some separate 
equipment and can be commanded through some management protocols/Interfaces. 

Communicatmg Overload Level to CoPI Apblicatioiis 

There Is an active way of informing applications about changes of tiie overtoad level by event 
and a procedural interface that makes tiie overtoad levels available. 

The exact mechanism (message type, interface and procedure) Is defined for each application or 
process. The diversity of applications, processes and their manufacturer does not allow a common 
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treatment That Is the reason why the overload treatmmt has to be federated into a single control system 
that deddes and then distributes overload rejection/reduction actions. 

Possible means to achieve the communication of the overload levels and actons to the applications and 
processes are: 

- . messaging interface, 

- UMi-AAPI, 

- Open Third Party APIs, 

- Network Management Protocols (SNMP...). 

All these options will be discussed in dedicated paragraphs for the OSP and the PCU. 

rnmrminicatiii^ Ove rload Level t ft rHTier PlflffhrinQ 

For sevenal load control idated pmposes load kivek need to be distributed by OoPl load cantrol to atbsjs but Hie 
owiLplatfbnii. 

Possible means to achieve the communication of the overload levels and actions to the applications and 
processes are: 

- messaging interface (LTG. EWSD (CP), Proxies), 

- Network Management Protocols (SNMP...). 

Ail these options wiii be discussed in dedicated paragraphs for the OSP and the PCU. 

4.3 Overioad Management for the OSP 
4.3»1 Overview 

The new hlQ 4000 Open Service Platform (OSP) adjunct to the SUFIPASS hiQ91 00/9200 or the EWSD, 
making use of their call control capabilities, provides old and new ISS sersn'ces like CWI, EWI and Ciickr 
To-Phone. The Commercial Platform of the OSP and the applications running on have been described In 
the BOs 262, 233 and 340. 

In order to achieve a carrier grade level, load control and overload handling mechanisms have to be 
implemented within the OSP. Because of the quick evolution of such services and possible changes in 
the architecture, overload-handling mechanisms have to remain flexible and adaptable for new 
requirements. 

Therefore the proposed concept Is particularly well adapted to the OSP. Each time a new module or a 
new application is inserted Into the exIsUng OSP architecture, only little changes in the system 
configuration file and the overload communication module are needed. 

Specificity and Architecture 

The OSP hosts or will host most of the Internet Supplementary Services (ISS) like CWI, EWI or the Cllclc- 
To applications. Some of these applications were hosted until now on separate servers and will be ported 
to the OSP (BO262/233/340). 

Following ISS services are described in the BO340: 

- Intemet Call IManager 

- Ciick-to-Conference 

- Prepaid Service ' 

- Synchronized Surfing 

- Push and Poll Services 



4^.3 Interfaces 

The ISS applications running on tiie OSP need diverse interfaces to external equipment like- CP (EWSD) 
/hiQ10/20/30 /Databases/ Clusters T1 120. ^ 

The interfaces will be described for each application. 



43A Platform Overload Treatment 
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Platform Oveiload Treatment is the overioad treatment needed for the platfonn when no particular 
aoplicatlon is responsible for the overioad situation. This can be conditioned by external appHcations or 
platfbmis. like for example overtoad status received by the OSP from the EUVSD/hiQ9200. It can also 
happen for a global overload situaHon where system software or modules (OS) are responsible. 
If the overioad comes from a received overioad status from higher priority systems like the 
E\AraD/hiQ9200 (CP overioad for Instance), then the OSP has to enter an higher overioad level et reduce 
its load to this machine. 

43.5 Applicatioiis Overload Treatment ^ . . ^ . .x..^ 

Each time possible, the applications should have a Wnd of Integrated Call Admission Control that checks 

the last known overioad status. 

This overioad status can be different for each application, forcing it to react differently against the load 
situation. This allows a higher flexibility forthe overtoad treatment mechanisms. 

Depending on the inter-process communicaUon capabillHes of the considered application, Its dedicated 
overioad status will be delh^ered to It (OTP/OTRP or OTCP) or will be available for polling from the OTP 
(OTCP), 

According to its overload level, the application can drive different strategies, flke delaying or refusing new 
incoming requests. 

The new Incoming requests should be stopped, when possible, not In the application itself, but in the 
processes that are at the beginning of the call/request processing. But. If these processes are used from 
other applications that are not in an overioad situation requiring some overioad treatment, then the new 
incoming requests have to be stopped at the next level, alter leaving these processes and before anivlng 
at the considered application. This is done by configuring the fuzzy expert system with the correct set of 
rules. 

To t>e provided... 

4.3.6 Processes Overload Treatment 



To be provided... 



4.4 Overload Management for the PCU 

4.4.1 Overview . - - 
Re-use BC>252/BO213/BO380/l-M VOIP C^rinecHon Agent for Virtual TfunWng and RAS. 

BO380AiyA 

4.4.2 Specificity 

VoIP Call Control / Protocol Translation Gateway / MGCP / H.323 / FT1 800 

4.4.3 Interfaces 

4.4.4 Platform Overload Treatment 

Platfonn Overioad Treatment is the overioad treatment needed for the platform when no particular 
application is responsible for the overioad sltuaflon. This can be condiHoned by Vernal applications or 
platfomis, 8ke for example overioad status received by the PCU from the EWSD/hlQ9200. It can also 
happen for a global overioad situation where system software or modules (OS) are responsible. 

If the overtoad comes from a recehfed overioad status from higher priority systems like the 
EWSD/hlQ9200 (CP overioad for instance), then the PCU has to enter an higher overioad level et reduce 
Its load to this machine. 

4.4.5 Applications Overload Treatment 

Each time possible, the applications should have a Und of integrated Call Admission Control that checks 
the last known overtoad status. 

This overioad status can be different for each application, forcing it to react differently against the load 
situation. This allows a higher flexibility for the overioad treatment mechanisms. 
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Depending on the Inter-process conimunication capabilities of the considered application, its dedicated 
overload status will be delivered to it (OTP/(OTRP or OTCP)) or will be avalable for polling from the OTP 
(OTCP). 

According to its overload level, the application can drive different strategies, like delaying or refusing new 
incoming requests. 

The new incoming requests should be stopped, when possible, not in the application itself, but in the 
processes that are at the beginning of the call/request processing. But, if these processes are used from 
other applications that are not In an overload situation requiring some overioad treatment, then the new 
Incoming requests have to be stopped at the neA level, after leaving these processes and before arriving 
at the considered application. This Is done by configuring the fuzzy expert system with the correct set of 
rules. 

To be provided... 

4.4»6 Processes Overload Treatment * 

To be provided... 



5 Interfaces 

Replace this line by the text body of the chapter 

5.1 Overview 

*** Replace this line by the text body of the chapter *** 

5.2 User Interfaces 

^ Replace this line by the text body of the chapter*** 

5.3 Interfaces to other Systems 

*** Replace this line by the text body of the chapter *** 

5.4 External Interfaces 

*** Replace this line by the text body of the chapter*** 

5.5 Internal Interfaces 

*** Replace this line by the text body of the chapter *** 

6 Message Flows 

7 Test Strategy 

*** Replace this line by the text body of the diapter*** 

8 Effects on other Systems 

*** Replace this One by the text body of the chapter*** 

8.1 <name of affected system n> 

*** Replace this line by the text l>ody of the chapter *** 

9 Appendix 

**• Replace this line by the text body of the chapter*** 

not_ag equ l-Hsper ; MOT * > NOT 
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mln^ag 
algp_ag 

algs_ag 

£_atid_ag 

f_or_ag 

mimaax ag 

prosumjag 

gaxntaa^ag 

algp__in 

2nlziinax_ln 

prosisa^la 

max^ac 

algs^ac 

minmaxjac 

prosuia^ac 

cog^de 

maxjde 

heigbjde 



eqii 2+oper 
equ 3+pper 
egu 44>oper 
equ 5+oper 
eqa 6+oper 
equ 7+oper 
equ 8+oper 
eqa 9+Qper 
eqa 10+oper 
equ 11+oper 
equ la-i-oper 
equ 13+oper 
equ 14+oper 
equ 15+oper 
equ 16+oper 
equ 17+oper 
egu 18+oper 
equ 19+oper 
equ 20-foper 
equ 21-H>per 



KEN 

algebraic product 
algebraic sum 

fuzzy^and vltta. gansna paraxneter 
fuzzy^or with gaaana paraxoeter 
jnin-max with gamma parameter 
prodact-'Bum operator with gamma 
gamma operator 
mvi 

algebraic product 
xEiin-max with gamma parameter 
product-*8um with gamma parameter ** 

max 

algebraic sum 

min-^max with gamma parameter 
product-sum with gamma parameter 
center of gravity 
maximum o£ set 
height o£ set 



-> AND 
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'-> OR 
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AND 
Gamma 
Gamma 
— > OR 
-> OR 
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•-*> Gamma 
.-> COG 
-> MAX 
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— > 
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The functional blocks of the ISS functionally on OSP are shown In the figure below. The element covered 
by UA 43814 is the ISM. 




CSS API 



INAP Protocol Handier 



Figure 34:ISS Function split on OSP 
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Figure 35: Application software components on OSP 



SIP/PINT+ messages for the applications (e.g. TTWl, CWl, CtD...) are recced from the IP Networic The 
SIP stack temiinates the protocol and parses these messages, authenticates them and transfers the data 
to ADF where the distribution of the messages is done. SIP: REGISTER mesrages are given to the ISM 
(ISS Session Manager) whereas the others (like SIP: OPTIONS, SIP: INVITE) are given to the relevant 
applications. The ISM handles ttie user registration datei and stores the IP Address infonnation and SUN 
(session related data, how the Client user c^n be reached). The applications like CtD, TTM or CWI are 
hsurudiing 

• the authorization of the call and 

• the feature logic. 

Messages from/to the hlQ are sent as TCAP messages via CSS API and INAP Protocol Handler. The 
INAP Protocol Handler Is responsible for the conversion of internal message fonmat into TCAP messages 
and vice versa 

ISM has oommurucation interfaces . . ... 

• to ADF and 

• to the ISS applications which requires a user Registration. 

In VI 5S the ISS Session Manager will be used by the CN\n application, only. 



10,1.1.1 CtD AppKcationfLM41899 lUS^ 
[Author : MrHeinridfi] 
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Intefoces in scope of IiM41899 
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Method invocation on UMLA wrapper objects / procedine call via JNI 
for IPQ access on DatabascTima?, Trace Polity, Alanmng; etc. 



,4.....^ TCAP primlfcves ibr invocation otXHAP operatioiis (vtaUMLA/l^lpc) 

N virtual connections CSS API operations (remote method invocation) 

1/ viaUMLA/OpCon ^ ^ ^ , ^. ^ 

2) Scrviee API operatlona gemote metbod mvocatum) 

33 PINT ASt (remote method invoca^on) 

PINT+ requests/responds over TCP/TP 




Securi^ Manager AH 
■ ■ ■ ■ CtDaientAH 



Figure 36 Overview over affected interfaces 
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Figure 37 : Call Prooessing for CtD call (Basic Call) 

The load for the machine is a result of two factors: The average call rate (number of requests per time) 
and the average call duration. The product of both is the number of stable calls. Every stable call has Its 
instances and entries in tables and need a certain amount of memory. 

It is not intended to limit the call rate via Service API to a certain value, but the number of service logic 
instances to avoid lack of memory. The maximum number of active CtD sessions is oonflgurable. 

In case the maximum number of GtD sessions is reached, all incoming requests via Service API >Artll be 
rejected \Artth operation raportEnor( overload ). 

[Author: Mr.Priem] 

For the CtD application, new incoming requests should be stopped already within the PINT+ GW 
Application by setting the overload level of the PINT+ GW Application high enough to stop processing of 
new incoming requests. 

If the Pir4T+ GW AppIicaHon is shared by other applications than the CtD application and these 
applications have a higher service priority level, then tiie overload level of the CtD application shall be set 
so that it does not authorize new sessions and the PINT+ GW application shall stay as before. 

Concretely, if the NOM detects an overload situation, it enters the COM. The COM then tests the 
overload status of the CtD application and the PINT-*- GW application. If the CtD application is the only 
connected application to tine PINT+ GW (see Rule 1), then the PINT+ GW application gets a higher 
overload level and starts r^ecting new incoming requests. If tiie CtD application shares the PINT-i- GW 
vwtii otiier applications having a Mgher priority level (see Rule 2), then it becomes Itself a higher overload 
level and starts itself rejecting new session attempts. 



It can be translated into two fuzzy logic rules: 
Rule1: 

IE OSPJOVERLOAD_HIGH 



i^ND CTD_ACTIVEJSESSI0NS_HIGH 
MB fNOT PINT+GWJSHARE_HIGH) 
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THEN PINT+GW_OVERLOAD_LEVEl^HlGH 

Rule 2: 

IE OSP_OVERLOAD_HIGH 

AND CTD jACTIVE.SESS10NS_HlGH 

PINT+GWJSHAR^HIGH 
THEN CrrDjOVERLOAD_LEVEU_HIGH 
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10.1.1.2 Applicatioii Distribution Function (ADF\ 
[KZilker. U.QuitterJ 

The application distribution function (ADF) is an upgrade to the PINT gateMvay (SSrPiGTW) of the 
hiQ9400 V1-soiution (see LM 41899 for more information). The programming language is JAVA with 
JDK 1.2.2. 

The ADF is located as single process (JVM) on the OSP and has as t>asic taslcs: 

• the control of StP-reiated messages in both directions, 

• the mapping and distribution of service-r^ated data to/from the sen^ice appli^on ISM. 
The location of ADF in the OSP can be found In Figure 34. 

The ADF as direct interface partner to the Internet Session Manager (ISM) uses the ISM Sen/ice AP. 

The ADF receives the SIP-message REGISTER vwth a sen^ce-fype CWI (coded as an URL-parameter 
in the request-UR() and distributes (t to the ISM application via the ISM Service API-message 
ISM_REGISTER. The ISM application ackno\wledges with the ISM Service API message 
ISM_REGISTER_RES, which indudes the actual status of the ISM-entry. The communication 
between ADF and ISM application is session-based, i.e. ADF has to create and maintain a session fcMr 
the Fifetime of the communication-cycle receipt of REGISTER/sending of RESPONSE. The session Is 
entered into the sessionUst of the ADF. The data for identification of the session is the Call-ID 
received from the SIP-requesL 

ptPriem] 



TTM Basic Call on OSP (all componenis) 




FigufB 38: Call Processing for TTM call (Basic Call) 

10 A J. Can Flows offhe BO 340 Converged Realtime Services 
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We present here the call flows of all considered Seivices. This allows to simply determine the overload 
treatment per service, 
• TTMV2 
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Figure 39: TTM Call e^bll^ment 
We consider here flie Talk-To-Me application. 
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Figure 40: TTM Call release (Unregistei???) 
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F/igfUf© 4Y: ICM registration and authorization 
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Bigfure 42: /C/W outgoing call establishment 
P30NNN-ANNNN-ANNN-XX-76J2 



50/95 



BULK 




F/gure 43: ICM Call re/ease for outgoing call 
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Figure 45: Initiation of an automatic conference 
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Figum 46: A conferee starts monitorhig 
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Figure 48: A conferee hooks on 
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Figure 50: CtC Create and join a synctimnized surfing session 
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FigufB 51: URL modification for SyS 
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Figure 52: End a conlBfence when the CC hooks on 
• Freecall wiflb ^diromzed Surfing 
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Figum 53: E^blishment of a Freec^l with SyS (part 1) 




Figure 54: E^JjIishment of a Freecatt wiOi SyS (part 2) 
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Figure 55: SyS sessipn with Freecall (part 1) 
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Figure 56: SyS session within Freecall (part 2) 




Figure 57: End of Freecall session 
• Prepaid Card Service (latemet initiated) 
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Figure 58: Prepaid Card Service call establistiment (internet initiated) 
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Figure 59: Prepaid Card Se/v/ce ca// terminaiiort (for Internet inUiated Prepaid call) 
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Overview of the functional software bloclts building the PCU on CoPI. 
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FlgufB 10-60: PCU soflvra/e structure overview 



10,1,2.1 Cotmection Agent for VoIP trmikmg and RAS 

The Connection Agent for VoIP tmnking and RAS consists of definition of appropriate states and 
evente and provides the Call processing logic to perform the required functionality. Therefore state- 
event coupling and handling of "connection-records" by specific "state-event-handlers" gets 
Implemented. 

The following fundamental scenarios are supported: 
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FigufB 10-61: Ba^c VoIP virtual trunking scenario 
Short description 

A-s!de: MMP supplies the A-side CA with MG-TSAIias information vwthin a SETUPJ message. \A*iich 
downloads the data via I\/1GCP to the M6. The MG returns the IP/RTP address of the A-side to the 
CA. The CA sends a SETUP_ACK with the IP/RTP address of the MG back to MMP. 

B-slde: The SETUP_E message from ttie MIWP contains the IP/RTP address of the A-slde and the 
IVIG-TSAlias infomnation for the B-side. The OA downloads these data to the MG. The MG returns its 
IP/RTP address to the CA, which transfers it to the A-side via transparent data In a FACILITY 
message. ....... 

A-side: \A/hen a FACILITY is received, the contained IP/RTP address of the B^ide is downloaded to 
the MG in order to complete the connection data. 
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FigufB 10S2: Basic VoIP RAS scenario 

ATOM connected user wants to surfin the internet In order to dial In, he sets up a (^1 y!«h ^eJ-^SJ 
number of his internet service provider. The IWIMP manages the sy«tohlng vwthm^^^ TDM and 
sends a SETUP I message >Arith RAS indication to the CA on the PCU. The MWIP supports the CA 
further with TDItftmnlc and MG infomiafion (MG-TSAlias). The CA downloads the date to the MG. 
where the requested TDM-IP connecHcn is created. The CA needs no exchangeof IP addresses or 
Codec Information with a partner CA since the Call consists only of a half CaO from the CA point of 
view. 
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Figure 10-63 :Loglcal po^on of CA for VoIP in sysfem 
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Figure 64: A conferee hooks on 
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Figure 65: CtC private Chat 
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Hgeim 66: CfC Create and Join a synt^ronked surfing session 
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Figure 67: URL modification for SyS 
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F/giir9 68: Ehcf a confemnce wtfen the CC fioolcs on 
• Freecall with ^yncbronized SurlBng 
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Figure 69: E^ablishment of a Freecall with SyS (part 1) 
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Figure 70: Estabiistiment of a Freecall with SyS (part 2) 
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Figum 71: SyS sess/on with Freecall (part 1) 
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Figure 72: SyS session witliin Freecall (part 2) 




Figure 73: End of Freecall session 
• Pre paid Card Scarvice flhtemet initiated) 
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F^uiB 74: Prepaid CanJ Service call establishment (Internet Initiated) 




Figure 76: Prepaid Card Senrice call termination (for Internet initiated Prepaid call) 
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Ov^view of the funcSonai sGfhware blocks building the PCU on CoPI. 
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Figum 10-76: PCU software structure ovenriew 



10,1,2,2 Coimection Agent for VoIP tnmk ing and R AS 

The Connection Agent for VoIP tainking and RAS consists of definttion of appropriate states and 
events and provides the Call processing logic to perform the required func^onality. Therefore state- 
event coupling, and handling of "connection-records" by specific "state-event-handlers" gets 
Implemented. 

The following fundamental scenarios are supported: 
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Figure 10-77: Basic VoIP virtual trunking scenario 
Short description 

A-slde: MMP supplies the A-^'de CA with M&-TSAfias information within a SETUPJ message, which 
downloads the data via MGCP to the MG, The MG returns the IP/RTP address of the A-side to the 
CA The CA sends a SETUP_ACK with the iP/RTP address of the MG back to MWIP. 

B-8lde: The SETUP_E message from the MMP contains the IP/RTP address of the A-side and the 
MG-TSAIias Infonnation for the B-^de. The CA downloads these data to the MG. The MG returns its 
IPTRTP address to the CA, which transfers it to the A-side via transparent data in a FACILITY 
message. 

A-slde: When a FACILnY is received, the contsdned IP/RTP address of the &side Is downloaded to 
the MG in order to complete the connection data 
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Figura 10-78: Basic VoIP RAS scenario 

A TDM connected user wants to surf in the internet In order to dial in, he sets up a Call with the E. 164 
number of his internet service provider. The MMP manages the switching within the TDM net and 
sends a SETUPJ message with RAS indication to the CA on the PCU. The MMP supports the CA 
further with TDM" trunk and M6 Infomnafion (M6-TSAIias). The CA downloads the data to the MG. 
where the requested TDM-IP connecSon is created. The CA needs no exchange of IP addresses or 
Codec information with a partner CA dnce the Call consists only of a half Call firom the CA point of 
view. 
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F^ure 10-79 -.Logical po&Hon ofCAfcxr VoIP in system 
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We claim: 

1. A method for controlling overload of a data processing 
system, comprising: 

5 a) monitoring a load of said data processing system, 

whereby parameters for a degree of utilisation of re- 
sources of said data processing system are determined, and 
b) running an overload operation mode (OOM) of said 
data processing system, including the steps of 
10 1) feeding said parameters into a fuzzy logic expert sys- 

tem, which comprises a fuzzy rule base having rules 
and associated fuzzy logic variables, 

2) identifying important rules among said rule base in 
accordance with said parameters via said fuzzy logic 

15 expert system, and 

3) calculating values for the fuzzy logic variables, 
which are associated with the important rules, and 

4) handling the overload based on the identified rules . 
and the calculated values of said associated fuzzy 

20 logic variables. 

2. The method according to claim 1, further comprising:- . 
rvmning a normal operation mode (NOM) of said data proc- 
essing system, 

25 

3. The method according to claim 2, further comprising: 
monitoring the load of said data processing system, in- 
cluding the steps of 

a) determining parameters for said degree of utilisation of 
30 resources of said data processing system in both the nor- 
mal operation mode and the overload operation mode, and 

b) feeding said parameters into said fuzzy logic expert sys- 
tem, 

c) detenaining additional application specific parameters, 
35 which refer to the degree of utilisation of resources by 

applications running on said data processing system, in 
the overload operation mode, and 



200201198 



• 



2 

d) feeding said application specific parameters into said 
fuzzy logic expert system. 

4. The method according to claim 3, further comprising: 
a) determining an overload level via said fuzzy logic 

expert system based on said parameters and/or said appli- 
cation specific parameters, and 
b using said overload level as criterion for switching 
between the normal operation mode (NOM) and the over- 
load operation mode (OCM) . 

5. The method according to one of the claims 1 to 3, wherein 
the monitoring of the load of said data processing system 
is perfoinaed according to a clock rate, which is higher in 
the overload operation mode than in the normal operation 
mode . 

6. The method according to one of the claims 1 to 5, wherein 
the degree of utilisation of at least one of the following 
resources is monitored: CPU load, memory utilisation, I/O 
load. 
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